Amazon API Gateway REST APIs: Resources, Methods, and Integrations – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon API Gateway provides a managed front door for applications that need to communicate with backend services through APIs. It is especially useful when a client such as a mobile application or web application must access multiple microservices through a single public HTTPS endpoint.

This lesson focuses on the structure of an API Gateway REST API: resources, HTTP methods, and backend integrations.

Key Concepts

API Gateway as a Single Entry Point

Without an API gateway, a client might need to know the individual endpoint for every backend service. API Gateway presents one public API endpoint and routes requests to the appropriate backend based on the request path and HTTP method.

A simplified request flow is:

Client application
        |
        | HTTPS request
        v
Amazon API Gateway
        |
        | Route based on resource and method
        v
Backend integration
(Lambda, ECS, HTTP service, DynamoDB, and others)

For example, a mobile application might use paths such as:

/booking
/payment
/account

Each path can be connected to a different microservice or backend operation.

Resources Represent API Paths

In a REST API, a resource represents a path relative to the API endpoint. A resource can correspond to a business capability, entity, or operation group.

Examples include:

/booking
/inventory
/payment
/submit-ticket

The resource identifies *which part of the API* the client is addressing. It does not, by itself, specify what operation the client wants to perform.

Methods Represent Operations

HTTP methods define the operation requested against a resource. Common methods include:

GET for retrieving data
POST for submitting or creating data
PUT for updating or replacing data
DELETE for removing data

For example:

GET  /booking       Retrieve booking information
POST /booking       Create or submit a booking
PUT  /booking       Update booking information
DELETE /booking     Remove a booking

The combination of the resource path and HTTP method determines the API operation that API Gateway invokes.

Integrations Connect Methods to Backends

Each method can be configured with an integration that sends the request to a backend. Possible integrations include:

AWS Lambda functions
HTTP endpoints
Services running on Amazon ECS
Amazon DynamoDB and other AWS services, where supported by the API design
Additional application backends

A single API can therefore expose several different microservices through one consistent client-facing interface.

For example:

POST /send-email     -> Lambda function that sends a support email
POST /submit-ticket  -> Lambda function that writes a ticket to DynamoDB
GET  /account        -> Account service running on ECS
POST /payment        -> Payment microservice

REST APIs Use HTTPS for Client Communication

Clients communicate with the API endpoint over HTTPS. This provides encrypted transport between the client and the public API endpoint. Backend integration behavior and authorization still need to be designed and configured appropriately; HTTPS alone does not define application authentication or authorization.

Exam-Relevant Takeaways

API Gateway can provide a single public entry point for multiple backend services.
Routing is based primarily on the API resource path and HTTP method.
A resource is a path such as /booking or /payment.
A method is an HTTP operation such as GET, POST, PUT, or DELETE attached to a resource.
Different methods and resources can integrate with different Lambda functions, HTTP services, ECS-based services, or AWS service backends.
API Gateway is useful for decoupling client applications from the location and implementation of backend microservices.
A client can use one API endpoint even when the underlying application consists of multiple independently deployed services.
Do not confuse an API resource with a backend resource. The API resource is the client-facing path; the integration is the destination that handles the request.

Architecture Decision Guide

Requirement	API Gateway design approach
Mobile or web clients need one public endpoint	Expose the application through an API Gateway API
Requests target different application capabilities	Create separate resources such as `/booking`, `/payment`, and `/account`
The same path supports different operations	Attach different HTTP methods to the resource
A request should invoke serverless application code	Integrate the method with an AWS Lambda function
A request should reach a containerized service	Integrate the method with an HTTP endpoint backed by ECS or another service endpoint
A request should submit data for processing	Commonly use `POST` and route it to the responsible backend integration
A client must retrieve existing information	Commonly use `GET` on the relevant resource
Several microservices must be presented as one application API	Use API Gateway as the client-facing facade and route each method to its backend

Common Exam Traps

Confusing the API endpoint with a resource: The endpoint is the public API address. A resource is a path appended to that endpoint.
Treating methods as backend services: GET, POST, PUT, and DELETE describe client operations. They are not AWS compute services.
Assuming one API must have one backend: A single API Gateway API can route different resources and methods to different integrations.
Assuming API Gateway replaces application logic: API Gateway routes and manages API requests; business logic is generally implemented by Lambda, containers, HTTP services, or other integrations.
Thinking HTTPS automatically provides authorization: HTTPS encrypts transport. Authentication and authorization require additional configuration and application design.
Routing only by URL: The method is also significant. GET /booking and POST /booking can represent different operations and integrations.
Assuming every backend must be Lambda: API Gateway can front containerized services and other HTTP or AWS service integrations as well.

Real-World Engineer Notes

Design resource paths around stable business capabilities rather than exposing internal implementation details. A client should not need to know which Lambda function or ECS service handles a request.
Keep the public API contract stable even if individual microservices are replaced or reorganized.
Use separate methods and resources to make request intent explicit. This improves maintainability and makes authorization and monitoring decisions easier.
For production APIs, consider authentication, authorization, request validation, throttling, logging, metrics, and deployment stages in addition to basic routing.
Avoid coupling a mobile application directly to multiple backend endpoints. A unified API reduces client-side service discovery and simplifies backend evolution.
Treat API paths and methods as a contract. Changes to them can require coordinated updates across client applications and backend services.

Quick Reference Summary

API Gateway: Managed front door for APIs and backend integrations.
Endpoint: Public address used by clients to reach the API.
Resource: Path within the API, such as /booking.
Method: HTTP operation attached to a resource, such as GET or POST.
Integration: Backend destination that processes the request.
Typical integrations: Lambda, HTTP services, ECS-based services, and supported AWS service integrations.
Primary architectural benefit: One client-facing API can represent many backend microservices.

Flashcards

1. What problem does API Gateway solve in a microservices application?

It provides a single client-facing API endpoint and routes requests to the appropriate backend services.

2. What is an API Gateway resource?

A resource is a path within the API, such as /booking or /payment.

3. What is an API Gateway method?

A method is an HTTP operation configured on a resource, such as GET, POST, PUT, or DELETE.

4. What determines which API operation is invoked?

The resource path and HTTP method together determine the operation.

5. Which HTTP method is commonly used to retrieve data?

GET.

6. Which HTTP method is commonly used to submit or create data?

POST.

7. Can one API Gateway API integrate with multiple backend services?

Yes. Different resources and methods can integrate with different Lambda functions, HTTP services, ECS services, or other supported backends.

8. What is the difference between an API resource and an integration?

The resource is the client-facing path; the integration is the backend destination that processes the request.

9. Why is API Gateway useful for mobile applications?

It gives the mobile application one stable HTTPS endpoint instead of requiring it to connect directly to each microservice.

10. Does HTTPS by itself implement application authorization?

No. HTTPS protects data in transit, while authentication and authorization require separate configuration and design.

Practice Questions

Question 1

A company has a mobile application that must access booking, payment, and account microservices. The booking and payment services run on Lambda, while the account service runs in ECS. The company wants the mobile application to use one public HTTPS endpoint. Which architecture best meets this requirement?

Correct answer: Use Amazon API Gateway with separate resources and methods integrated with the appropriate Lambda functions and ECS-backed service.

Explanation: API Gateway can expose one client-facing API and route requests based on paths and HTTP methods. The backend integrations do not all need to use the same compute service.

Question 2

An API design includes /support with both GET and POST methods. GET /support retrieves existing support information, while POST /support creates a new support request. What API Gateway configuration is required?

Correct answer: Configure the /support resource with separate GET and POST methods, each mapped to the appropriate backend integration.

Explanation: A resource identifies the path, while the method identifies the requested operation. The same resource can support multiple operations and integrations.

Question 3

A developer creates separate public endpoints for every microservice and requires the mobile application to call each service directly. The architecture team wants to reduce client-side coupling and expose a unified API. Which change should they make?

Correct answer: Place API Gateway in front of the services and route resource and method combinations to the relevant microservice integrations.

Explanation: API Gateway acts as a common entry point and hides backend service boundaries from the client. The mobile application can use one API contract while services remain independently implemented.

Question 4

An architect claims that configuring an API Gateway endpoint with HTTPS means that users are automatically authorized to call every API method. Which statement corrects this design?

Correct answer: HTTPS encrypts the connection but does not provide complete application authentication or authorization; those controls must be configured separately.

Explanation: Transport encryption and access control solve different problems. A production API must explicitly define how callers are authenticated and which resources or methods they may invoke.