Resources and methods in AWS - Commands & Configuration

Introduction

When you build an API on AWS, you need to organize how users access your backend. Resources are like folders or paths in a website, and methods are the actions users can do on those paths, like reading or writing data.

When you want to create a web API that users or apps can call to get or send data.

When you need to organize your API into different parts, like /users or /orders.

When you want to control what actions users can do on each part, like GET to read or POST to add data.

When you want to connect your API to backend services like AWS Lambda functions.

When you want to manage and secure your API endpoints easily.

Config File - api-gateway-template.yaml

api-gateway-template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyApi:
    Type: 'AWS::ApiGateway::RestApi'
    Properties:
      Name: 'MyExampleApi'
  UsersResource:
    Type: 'AWS::ApiGateway::Resource'
    Properties:
      ParentId:
        Fn::GetAtt:
          - MyApi
          - RootResourceId
      PathPart: 'users'
      RestApiId:
        Ref: MyApi
  GetUsersMethod:
    Type: 'AWS::ApiGateway::Method'
    Properties:
      HttpMethod: 'GET'
      ResourceId:
        Ref: UsersResource
      RestApiId:
        Ref: MyApi
      AuthorizationType: 'NONE'
      Integration:
        Type: 'MOCK'
        RequestTemplates:
          application/json: '{"statusCode": 200}'

This YAML file is a CloudFormation template that creates an API Gateway REST API named 'MyExampleApi'.

It defines a resource called 'users' under the root path.

It adds a GET method to the 'users' resource that returns a mock response with status code 200.

This setup shows how to organize resources and methods in AWS API Gateway.

Commands

This command deploys the CloudFormation template to create the API Gateway with resources and methods defined.

Terminal

aws cloudformation deploy --template-file api-gateway-template.yaml --stack-name my-api-stack

Expected Output

Waiting for stack create/update to complete...

Successfully created/updated stack - my-api-stack

→

--template-file - Specifies the CloudFormation template file to deploy

→

--stack-name - Names the CloudFormation stack for management

This command lists the resources (paths) of the deployed API to verify the 'users' resource exists.

Terminal

aws apigateway get-resources --rest-api-id $(aws apigateway get-rest-apis --query 'items[?name==`MyExampleApi`].id' --output text)

Expected Output

{

    "items": [

        {

            "id": "abc123",

            "path": "/"

        },

        {

            "id": "def456",

            "path": "/users"

        }

    ]

}

→

--rest-api-id - Specifies which API's resources to list

This command retrieves details about the GET method on the 'users' resource to confirm it is set up correctly.

Terminal

aws apigateway get-method --rest-api-id $(aws apigateway get-rest-apis --query 'items[?name==`MyExampleApi`].id' --output text) --resource-id def456 --http-method GET

Expected Output

{

    "httpMethod": "GET",

    "authorizationType": "NONE",

    "methodIntegration": {

        "type": "MOCK",

        "requestTemplates": {

            "application/json": "{\"statusCode\": 200}"

        }

    }

}

→

--resource-id - Specifies the resource ID to check the method on

→

--http-method - Specifies the HTTP method to retrieve

Key Concept

If you remember nothing else from this pattern, remember: Resources are the paths in your API, and methods are the actions users can perform on those paths.

Common Mistakes

Trying to create a method on a resource that does not exist yet.

The method creation fails because the resource path must exist before adding methods to it.

Always create the resource first, then add methods to it.

Using incorrect resource IDs when managing methods via CLI.

Commands fail or show wrong data because resource IDs are unique and must be accurate.

Retrieve and use the correct resource ID from the API before managing methods.

Summary

Use CloudFormation or AWS CLI to create API Gateway resources representing API paths.

Add methods like GET or POST to resources to define allowed actions.

Verify resources and methods exist using AWS CLI commands to ensure correct API setup.

Practice

1. What does a resource represent in AWS API Gateway?

easy

A. A URL path that clients can access

B. A backend database connection

C. A security policy for API access

D. A method to deploy the API

Solution

1. Step 1: Understand the role of resources in API Gateway

   Resources define the URL paths that clients use to reach your API endpoints.

2. Step 2: Differentiate resources from other components

   Resources are not backend connections, security policies, or deployment methods; they are URL paths.

3. Final Answer:

   A URL path that clients can access -> Option A

4. Quick Check:

   Resource = URL path [OK]

Hint: Resources are the API's URL paths clients call [OK]

Common Mistakes:

• Confusing resources with backend services
• Thinking resources are security settings
• Mixing resources with deployment steps

2. Which HTTP method is correctly defined in AWS API Gateway to retrieve data?

easy

A. GET

B. POST

C. DELETE

D. PUT

Solution

1. Step 1: Identify the HTTP method for data retrieval

   GET is the standard HTTP method used to retrieve or read data from a resource.

2. Step 2: Confirm other methods' purposes

   POST creates data, DELETE removes data, and PUT updates data, so they are not for retrieval.

3. Final Answer:

   GET -> Option A

4. Quick Check:

   GET = retrieve data [OK]

Hint: GET method is for reading data from resources [OK]

Common Mistakes:

• Using POST instead of GET to fetch data
• Confusing DELETE with data retrieval
• Mixing PUT with GET for reading data

3. Given this API Gateway setup: a resource /items with a POST method integrated to a Lambda function. What happens when a client sends a POST request to /items?

medium

A. The API Gateway returns a static mock response

B. The API Gateway returns a 404 Not Found error

C. The Lambda function is triggered to process the request

D. The request is ignored because POST is not allowed

Solution

1. Step 1: Understand the integration of POST method with Lambda

   The POST method on the /items resource is connected to a Lambda function, so requests trigger that function.

2. Step 2: Analyze the client request effect

   When a client sends a POST request to /items, API Gateway forwards it to Lambda for processing.

3. Final Answer:

   The Lambda function is triggered to process the request -> Option C

4. Quick Check:

   POST + Lambda integration = Lambda triggered [OK]

Hint: POST method triggers Lambda if integrated [OK]

Common Mistakes:

• Assuming POST is not allowed without checking method setup
• Thinking API Gateway returns 404 if resource exists
• Confusing mock responses with Lambda integration

4. You created a resource /users and added a GET method, but clients get a 403 Forbidden error when calling it. What is the most likely cause?

medium

A. The client is using POST instead of GET

B. The resource path is misspelled

C. The API Gateway is not deployed

D. The method does not have an integration configured

Solution

1. Step 1: Check method integration setup

   A 403 Forbidden often means the method exists but lacks proper integration or permissions.

2. Step 2: Rule out other causes

   If the resource path was misspelled, the error would be 404. If API Gateway was not deployed, the error would differ. Using POST instead of GET would cause a 405 Method Not Allowed.

3. Final Answer:

   The method does not have an integration configured -> Option D

4. Quick Check:

   403 Forbidden = missing integration or permissions [OK]

Hint: 403 often means method lacks integration or permissions [OK]

Common Mistakes:

• Confusing 403 with 404 or 405 errors
• Ignoring deployment status
• Assuming client method is always correct

5. You want to create an API with a resource /orders that supports both GET and POST methods. The GET method returns a mock response, and the POST method triggers a Lambda function. Which configuration correctly sets this up?

hard

A. Create /orders resource; add GET and POST methods both with MOCK integration

B. Create /orders resource; add GET method with MOCK integration; add POST method with Lambda integration

C. Create /orders resource; add GET method with Lambda integration; add POST method with MOCK integration

D. Create /orders resource; add GET and POST methods both with Lambda integration

Solution

1. Step 1: Match method to integration type

   The GET method should use MOCK integration to return a static response without backend calls.

2. Step 2: Configure POST method to trigger Lambda

   The POST method must be integrated with Lambda to process incoming data.

3. Step 3: Verify the correct combination

   Create /orders resource; add GET method with MOCK integration; add POST method with Lambda integration correctly assigns MOCK to GET and Lambda to POST on the /orders resource.

4. Final Answer:

   Create /orders resource; add GET method with MOCK integration; add POST method with Lambda integration -> Option B

5. Quick Check:

   GET=MOCK, POST=Lambda [OK]

Hint: GET with MOCK, POST with Lambda for mixed behavior [OK]

Common Mistakes:

• Swapping MOCK and Lambda integrations between methods
• Using same integration for both methods incorrectly
• Forgetting to create the resource before methods