The content below is taken from the original (API Gateway Update – New Features Simplify API Development), to continue reading please visit the site. Remember to respect the Author & Copyright.
Amazon API Gateway allows you to quickly and easily build and run application backends that are robust and scalable. With the recent addition of usage plans, you can create an ecosystem of partner developers around your APIs. Let’s review some terminology to start things off:
Resource – A named entity that exists (symbolically) within an endpoint, referred to by a hierarchical path.
Behavior – The action that your code will take in response to an HTTP request on a particular resource, using an HTTP method.
Integration – The API Gateway mapping from the endpoint, resource, and HTTP method to the actual behavior, and back again.
Today we are extending the integration model provided by API Gateway with support for some new features that will make it even easier for you to build new API endpoints and to port existing applications:
Greedy Path Variables – Instead of specifying individual paths and behaviors for groups of requests that fall within a common path (such as /store/), you can now specify a “greedy” route that intercepts all requests to the path and routes them to the same function. For example a single greedy path (/store/{proxy+}) will intercept requests made to /store/list-products, /store/add-product, and /store/delete-product.
ANY Method – Instead of specifying individual behaviors for each HTTP method (GET, POST, PUT, and so forth) you can now use the catch-all ANY method to define the same integration behavior for all requests.
Lambda Function Integration – A new default mapping template will send the entire request to your Lambda function and then turn the return value into an HTTP response.
HTTP Endpoint Integration – Another new default mapping template will pass the entire request through to your HTTP endpoint and then return the response without modification. This allows you to use API Gateway as an HTTP proxy with very little in the way of setup work.
Let’s dive in!
Greedy Path Variables
Suppose I am creating a new e-commerce API. I start like this:
And then create the /store resource:
Then I use a greedy path variable to intercept all requests to any resource within /store (I also had to check Configure as proxy resource):
Because {proxy+} routes requests for sub-resources to the actual resource, it must be used as the final element of the resource path; it does not make sense to use it elsewhere. The {proxy+} can match a path of any depth; the example above would also match /store/us/clothing, /store/us/clothing/children, and so forth.
The proxy can connect to a Lambda function or an HTTP endpoint:
ANY Method
I no longer need to specify individual behaviors for each HTTP method when I define my resources and the methods on them:
Instead, I can select ANY and use the same integration behavior for all of the methods on the resource:
This is cleaner, simpler, and easier to set up. Your code (the integration point for all of the methods on the resource) can inspect the method name and take an appropriate action.
The ANY method is created automatically when I use a greedy path variable, as shown above. It can also be used for individual resources. You can override the configuration for an individual method (perhaps you want to handle DELETE differently), by simply creating it and changing the settings.
Lambda Function Integration
It is now easier than ever to implement a behavior using a Lambda function. A new, built-in Lambda integration template automatically maps the HTTP request elements (headers, query parameters, and payload) into a form directly consumable by the function. The template also maps the function’s return value (an object with status code, header, and body elements) to a properly structured HTTP response.
Here’s a simple function that I copied from the documentation (you can find it in [Lambda Function for Proxy Integration]):
I connected it to /store like this:
Then I deployed it (not shown), and tested it out like this:
The function ran as expected; the console displayed the response body, the headers, and the log files for me. Here’s the first part:
Then I hopped over to the Lambda Console and inspected the CloudWatch Logs for my function:
As you can see, line 10 of my function produced the message that I highlighted in yellow.
So, to sum it all up: you can now write Lambda functions that respond to HTTP requests on your API’s resources without having to spend any time setting up mappings or transformations. In fact, a new addition to the Lambda Console makes this process even easier! You can now configure the API Gateway endpoint as one of the first steps in creating a new Lambda function:
HTTP Function Integration
You can also pass API requests through to an HTTP endpoint running on an EC2 instance or on-premises. Again, you don’t have to spend any time setting up mappings or transformations. Instead, you simply select HTTP for the integration type, click on Use HTTP Proxy integration, and enter the name of your endpoint:
If you specify an HTTP method of ANY, the method of the incoming request will be passed to the endpoint as-is. Otherwise, the method will be set to the indicated value as part of the call.
Available Now
The features described above are available now and you can start using them today at no extra charge.
— Jeff;
