After covering an introduction to API Gateway, there are a few more concepts and details to learn before we create our own API. We'll start by reviewing the concepts then explain some of the ways to create and build APIs.

An API built and deployed to Amazon API Gateway is made up of resources, methods, and integrations. To show examples of what these look like in the console, we're going to use a real API that has been built to control the garage doors at home.

Don't worry, this API has the proper security controls in place:

First up are resources, which are the logical entities that make up the path of an API. You can see at point number (1) on the preceding screenshot that I have created /garages, which is the superset for all of my garage IDs in /{id}. The curly brackets are to denote a variable. Under each resource, there are several methods (2). This is a combination of the resource path and an HTTP verb and can be considered in REST as an action or operation on that particular entity. For example, I can send a GET request to /garages/2 and expect to see all of the details that are relevant to the garage with ID = 2. We have clicked into the Resource page and clicked on a particular method, so we are presented with the method execution overview. This shows a nice representation of the request/response flow when an API is invoked. Around point (3), we can see the details of the integration; in this case, it is with a Lambda function.

Let's click into the Integration Request and see what's available. This page shows us a drill-down of all of the options available; see the following screenshot:

Here, we can see the options for changing the type of integration; note that we have a Mock type available. This is a common feature of API Gateways and integration solutions and allows a developer to create an API without the implementation of business logic so that other teams can develop against the expected API response in parallel.

The next feature is Lambda proxy integration, which allows a builder to pass everything from the request straight to the Lambda without manipulation or transformation. To use this, you can set a path variable of {proxy+} with a method of ANY (which means all methods). This functionality will detach the API specification from the implementation and allow for greater flexibility in Lambda development since it will accept any path and method. The downside is that the client now has to know a lot more details about what is built in the backend because they can't check an API specification for the supported requests.

Further down the page, we see some hidden sections to create data mappings. These are input mappings and you can also create output mappings during the Integration Response flow. Using mappings is a way to transform requests into support for your integrations and can be used in reverse to support a client. An example of this is transforming a response from JSON into XML. There's a specific syntax for creating models to map templates; we're not going to get into that in this book.

Moving on, the following are the ways in which we can build APIs using API Gateway in AWS:

• The API Gateway console is a good way to prototype ideas, run ad hoc tests, and visually check on the current state. If you were building and deploying regularly to production, then you would hopefully be using a continuous integration pipeline to facilitate that. In that situation, you need something more powerful than the console.
• The API Gateway CLI is useful for making changes quickly or programmatically. Like the console, commands can be issued on the fly without a whole lot of change governance. 
• Infrastructure as Code is possible using AWS CloudFormation. This is when you declare the details of an API in a template written in JSON or YAML. The template file is then deployed to the CloudFormation service, which takes care of creating or updating the AWS resources. Infrastructure as Code is great because you can store the templates in source control, which enables versioning by design and allows multiple parties to work on the build. Approving a new release to be deployed becomes a matter of reviewing the difference created in the pull request.
• Some builders prefer to define their APIs in an industry-standard specification format. API Gateway supports importing APIs written within Swagger, or the OpenAPI specification as it's now called. There are also extensions for the OpenAPI specification to support authorizer types and the data mapping functionality.
• Finally, in my opinion, the best workflow for developing APIs with Lambda and other resources is to use an application framework. Examples include AWS Serverless Application Model, Serverless Framework, AWS Cloud Development Kit, and the AWS Chalice microframework. These are really good because it allows you to pair your API definitions with your implementation code. Serverless Framework is particularly awesome because it can take your Lambda code and event mappings, create a CloudFormation template, bundle everything up, and deploy them. It also comes with a CLI for deployment and management. This really is the best of all of the options for building production APIs.

Now we understand the concepts involved when we talk about building APIs using API Gateway. After we build something, we need to be able to deploy it so that users can interact with the service. We'll cover deploying APIs in the next section.