REST API

REST API with API Gateway

The REST API offered by the API gateway is based on a request/response model where the client sends the request, and the server responds to it synchronously. The Rest API in API Gateway had three main components: resources and methods, HTTP endpoints, and integrated services.

Let’s learn about them in detail.

Integrations

In API Gateway, integration refers to the process of connecting and coordinating the communication between an API and backend services or other AWS resources. Integration is a crucial aspect that defines how client requests to the API are handled, processed, and fulfilled by the underlying backend systems. We’ll learn more about integrations ahead.

HTTP endpoints

In API Gateway, HTTP endpoints in a REST API represent the URLs through which clients can interact with your API. These endpoints define the structure and behavior of the API, including the supported HTTP methods (GET, POST, PUT, DELETE, etc.) and the associated resources.

Methods and resources

Resources represent entities or objects that are the targets of the API requests. In API Gateway, we can connect to multiple resources, and each resource can be associated with various methods, such as GET, PUT, and more. Ultimately, each combination of a resource and a method results in a distinct integration within the API Gateway.

What does this imply? While there is a singular base URL for invoking an API, it encompasses multiple endpoints. To understand it, let’s consider an online bookstore API with two major resources: books and authors stored in a database.

Here are some examples of resources in our API:

• /books: This resource represents the collection of all books available in the bookstore.

• /books/{id}: This resource represents an individual book identified by its unique ID.

• /authors: This resource represents the collection of all authors associated with the books in the bookstore.

• /authors/{id}: This resource represents an individual author identified by their unique ID.

For the actions that clients can perform on resources, we define methods.

• GET /books: This method allows clients to retrieve a list of all books available in the bookstore.

• POST /books: This method allows clients to add a new book to the bookstore.

• PUT /books/{id}: This method allows clients to update the details of an existing book by providing its ID.

• GET /authors/{id}: This method allows clients to retrieve details of a specific author by providing their ID.

• DELETE /authors/{id}: This method allows clients to delete an author by providing its ID.

Deployment stages

While developing an API, developers may add new resources, methods, endpoints, and integration to add new features or manage load. A stage resource maintains a snapshot of these configurations. To ping an API endpoint, we must create a deployment and associate a stage with it. When we modify the deployment settings, we create a new stage. Unlike HTTP API, which automatically deploys the new stage, REST API requires explicit deployment.

Let’s understand it with the help of the slides given below. The illustration shows two stages of API Gateway. This means we have two snapshots of two API configurations. The dev stage shows that Lambda function V1 is integrated with API Gateway. Meanwhile, the prod stage integrates Lambda function V2 with API Gateway.

In the first image, we have deployed the API in dev stage. Thus, when the client sends a request to the API Gateway endpoint, it invokes the Lambda function V1. Similarly, the second image shows the API gateway deployed in the prod stage, which directs the client to the invocation of Lambda function V2.

Deployment stages provide isolated environments for deploying and testing API changes. This isolation ensures that changes made in the dev stage, do not affect the prod stage. Also, we can create staging environments to test and validate these stages before pushing them for production.

Example: E-commerce application

Until now, we have been discussing the features and working of API Gateway. Now, let’s see how developers have used it to solve their software application requirements. Consider the example of an e-commerce application’s various services, including user authentication, product catalog, and order processing. API Gateway can be a central component to streamline interactions and enhance the scalability and security of your system.

The API Gateway may integrate with other serverless services that provide the business logic and communicate with the database layer. The architecture diagram shown below could be on way to design the e-commerce application.

Here, the product catalog is stored in the instance of Aurora serverless. The API Gateway connects to the instance through the Lambda function, which performs CRUD operations. To restrict users’ access to certain endpoints, we integrate Amazon Cognito, which authenticates the user credentials before connecting to the endpoint. Finally, the orders placed by the users are qued into Amazon SQS FIFO which processes these orders and sends out confirmation to the users individually.