2.2 HTTP Endpoints

Hi, and welcome back to Introduction to Serverless. In this lesson, you are going to learn how to use functions as a service to create an API endpoint without the server. When you're building an API that is supposed to be serverless, you need a trigger to execute a function that is able to route requests from the web to your function. I am going to focus on Amazon Web Services in this lesson, as Google Cloud functions and Microsoft Azure functions have the HTTP triggers built into the function itself. Which makes it easy to set up, but harder if you want to have separate environments for testing. I'm going to jump right into the console for this lesson, because this topic is something that is best learned hands-on. So here we are back in the console. As before, you could just type API Gateway into the search field or go to services, and on the far right to Application Services, where you'll find API Gateway. If you haven't created an API before yourself, or have one created for you by another service, you will be greeted with this Getting Started page. Now let's create an API. It will give you three options. If you already have an API, it will also offer you to clone it. AWS has support for importing from Swagger, which is a very popular API documentation framework. This can save you a lot of work if you have a lot of endpoints. There is also an example API that in fact is a Swagger file, or you can create one from scratch. When you use Swagger, you will define the name of the API within the file. When you create a blank one, you have to provide it yourself. Let's use the example API. It will create a gateway that has one root resource and inside one for pets, as well as another with a variable. A resource on its own is pretty useless, as you can't access it from the web. That's why you can also define my thoughts for the resources. For instance, pets has a get and a post resource, as well as an options method for cross origin resource sharing, or CORS. You might already be thinking that having support for Swagger is pretty useful because it makes setting up all resources and methods so much easier. So let's have a look at the method. As you can see, there are four parts to it, two on the request and two on the response side. The method request is used to authorize and validate the request, making sure the client is allowed to access the resource. And all required parameters are present. In this case, the method states that there is a page and a pets type parameter in the request. If you leave some out here, it doesn't really matter if they are purely optional as you will have access to all parameters later in the pipeline. Next is the integration request, which is the point where we tell the request where to go. Here you have four options, positive lambda function, which is what we are going to do. Here's another HTTP endpoint. Provide a mock endpoint that uses predefined mapping and transformation, or use another AWS service like Kinesis or S3. Here you can pass an extra name like list streams or get object to be executed. When you select lambda functions as the target, you need to select the region of your function first and are then able to provide the function name. Amazon helps you by listing already created functions. To be able to use the query parameters, we need to redefine a body pre-made template for application/json. I'm using the pre-made template to just pass all the data to the lambda function, which also adds a lot of metadata. To show you the integration response, I'm going to switch to the root GET method. As you can see, you can define different responses based on received data. If you use a lambda function to process a request, it will ask for a lambda error pattern. The reason why I use this specific method was because by default, AWS uses an HTML body mapping template that returns static HTML. But you could also change this to three dynamic values. Like displaying a past price dollar with dollar inputs to params and pass the price argument. The final piece of the puzzle is method response. This allows you to further transform a request based on the response that is code, adding headers and defining models with attributes that should be returned. Let's leave it as it is. Now it's time to try our API, but it isn't available yet. We have to deploy it first. Deployments allow you to patch API changes and control which stage you want to deploy to. Since there isn't a stage four example yet, we can create one in line. I'm calling it prod to indicate a production environment. Each deployment can also have a description, so you know what was changed. The API is now live, and we can access it by using the URL provided to us. I chose a static template, which I showed you before. And if you use price as a query parameter, it dynamically shows the value. Before I'm going to show you the execution of the end point that has lambda function attached, I'm going to change this very function to return the complete event back to the API. So we can see what was passed in directly in the browser. Instead of returning key1, let's return the complete event. Now when we visit the Pets endpoint, you can see all the parameters, headers, and other context metadata. When I add the pet type of cat, it also shows up in the querystring params. And we can work with that and learn them. To recap, the AWS API Gateway is a powerful tool to create custom APIs with different endpoints. You can deploy your API to stages which allows you to test it first in other environments. A request is going through two request and two response transformations. In the next lesson, I'm going to connect other services to our endpoint and interact with them. You will also learn what you need to upload a ZIP file instead of writing a function inline. See you there.