I like the feature a lot, but I'd do it a bit differently, so instead of:

- http:
       path: posts/create
        method: post
        parameters:
           method.request.querystring.url: true
           method.request.header.x-foo: false
           method.request.path.bar: false

We have

- http:
          path: posts/create/{bar}
          method: post
          request:
             headers:
               foo: false
             querystrings:
                url: true
             paths:
                bar: false

This brings it in line with the request property and easily allow users to include standard variables through `${self:custom.querystrings}.

Thoughts?

@flomotlik I used a 1 on 1 mapping of AWS, perhaps it's even better to move them under parameters, so that it's easier to add other variables to request later (perhaps for other providers)? Like so:

- http:
  path: posts/create
  method: post
  request:
    parameters:
      header:
        foo: false
      querystring:
        url: true
        foobar: false
      path:
        bar: false

yup parameters makes sense. Only change I would do from your example is use plural for headers, querystrings, paths. Paths is strange though, but changing it to pathVariables is also weird.

@svdgraaf as AWS have now released the new APIG implementation I think it makes sense to pick up this PR and implement/merge it. Let me know what the next steps are.

I'll look into it on monday, update from master and check for other loose ends

@flomotlik all good to go now 😄 The config is now plural as you requested:

- http:
    path: posts/create
    method: post
    request:
      parameters:
        headers:
          foo: false
        querystrings:
          url: true
          foobar: false
        paths:
          bar: false

/cc @flomotlik

@svdgraaf one quick question. How do I test the paths parameter? If I set one up through the serverless.yml file it won't show up in the API Gateway console (it just says that I should add it in the resource path).

Here's the corresponding serverless.yml file:

- http:
    path: foo
    method: GET
    request:
      parameters:
        paths:
          bar: true

@pmuens I'm not sure actually, I only used the header and query parameters. I'll see if I can build an example (and document it).

@svdgraaf thank you very much! That would be great! 👍

Other than that the parameter support works really well! Good job!

Ok, I've put some time in it, and I know what the problem is.

The issue is that path parameters are actually not supported via the RequestParameters, or at least, it's very badly documented. For the path parameters to work, you need to add the parameter to the path, like so: /foo/{url}/, which will generate an endpoint path with url as path parameter.

However, I see that there currently is an issue with this PR, as that when you make such an endpoint, it will not set any other RequestParameters that you have defined (eg: the headers/params). I have to find some time to find out why.

@svdgraaf thanks for looking into it. Yes I was also struggling to find some resources on how to use path parameters.

Great that you're about to tackle it. Let me know if you need any help there. 👍

Ok so we're waiting on this PR for now @svdgraaf correct?

@flomotlik yeah, let's not merge it just yet until I have time to work on this, probably this weekend or Monday.

Ok, got it, the problem is just that it's badly documented. I added another paragraph in the documentation with a sample: 1b1ce33

If you define a function with a paths request parameter, it just has to be added to the method path as well, like so:

# serverless.yml
functions:
  create:
    handler: posts.post_detail
    events:
      - http:
          path: posts/{id}
          method: get
          integration: lambda
          request:
            parameters:
              paths:
                id: true
              querystrings:
                bar: true

Which will end up in api gateway like so:

btw: you could leave the paths out of the request parameters, and the paths parameter would still show up on the test screen. The defined request parameters are mainly for testing and generating sdk's (eg: swagger), so it does makes sense somewhat (it's just very poorly documented).

something broke after the rebase with master, let me figure out why ;)

@pmuens can you check again if this is now satisfactory? :)

Cool stuff @svdgraaf 🌮 🎉 Thank you very much!

I'm able to define a function as below and access the id path parameter in code using event.pathParameters.id.

functions:
  getItem:
    handler: handler.getItem
    memory: 512
    timeout: 60
    events:
      - http:
          method: get
          path: items/{id}
          cors: true

@jch254 Your comment to get Parameters should be in Docs.