REST API creation in AWS - Time & Space Complexity

Time Complexity: REST API creation

O(n)

Understanding Time Complexity

When creating a REST API on AWS, it's important to understand how the time to set up and respond grows as you add more resources or requests.

We want to know how the number of API calls or operations changes as the API grows.

Scenario Under Consideration

Analyze the time complexity of the following operation sequence.

// Create REST API
aws apigateway create-rest-api --name MyApi

// Create resource for each path
aws apigateway create-resource --rest-api-id apiId --parent-id rootId --path-part resourceName

// Create method for each resource
aws apigateway put-method --rest-api-id apiId --resource-id resourceId --http-method GET --authorization-type NONE

// Deploy API
aws apigateway create-deployment --rest-api-id apiId --stage-name prod
    

This sequence creates a REST API, adds resources and methods for each path, and deploys it.

Identify Repeating Operations

Identify the API calls, resource provisioning, data transfers that repeat.

• Primary operation: Creating resources and methods for each API path.
• How many times: Once for the API, then once per resource path added.

How Execution Grows With Input

Each new API path requires creating a resource and a method, so the number of operations grows as you add more paths.

Input Size (n)	Approx. Api Calls/Operations
10	About 21 (1 API + 10 resources + 10 methods)
100	About 201 (1 API + 100 resources + 100 methods)
1000	About 2001 (1 API + 1000 resources + 1000 methods)

Pattern observation: The number of operations grows roughly in a straight line as you add more API paths.

Final Time Complexity

Time Complexity: O(n)

This means the time to create the API grows directly in proportion to the number of paths you add.

Common Mistake

[X] Wrong: "Creating the API once means adding many paths is still fast and constant time."

[OK] Correct: Each path requires separate resource and method creation, so the total work grows with the number of paths.

Interview Connect

Understanding how API creation scales helps you design efficient cloud solutions and shows you can think about growth, which is valuable in real projects.

Self-Check

"What if we batch resource and method creation in fewer API calls? How would the time complexity change?"

Practice

1. What is the main purpose of creating a REST API in AWS?

easy

A. To store large amounts of data securely in the cloud.

B. To allow different applications to communicate over the internet using defined paths and actions.

C. To run virtual machines for hosting websites.

D. To create user accounts and manage permissions.

Solution

1. Step 1: Understand REST API purpose

   REST APIs enable communication between apps using simple commands over the internet.

2. Step 2: Identify AWS REST API role

   In AWS, REST APIs define resources (paths) and methods (actions) to allow this communication.

3. Final Answer:

   To allow different applications to communicate over the internet using defined paths and actions. -> Option B

4. Quick Check:

   REST API = communication interface [OK]

Hint: REST APIs connect apps via internet paths and actions [OK]

Common Mistakes:

• Confusing REST API with data storage services
• Thinking REST API runs virtual machines
• Mixing REST API with user management

2. Which AWS service is primarily used to create REST APIs?

easy

A. Amazon API Gateway

B. AWS Lambda

C. Amazon S3

D. Amazon EC2

Solution

1. Step 1: Identify AWS services for APIs

   Amazon API Gateway is designed to create, publish, and manage REST APIs.

2. Step 2: Differentiate other services

   Amazon S3 stores files, Lambda runs code, EC2 runs servers, but API Gateway manages APIs.

3. Final Answer:

   Amazon API Gateway -> Option A

4. Quick Check:

   API Gateway = REST API service [OK]

Hint: API Gateway is the AWS REST API builder [OK]

Common Mistakes:

• Choosing Lambda as the API creator
• Confusing S3 with API service
• Selecting EC2 for API management

3. Given this API Gateway setup: a resource path /books with a GET method using MOCK integration. What happens when a client sends a GET request to /books?

medium

A. The API fetches book data from a connected database.

B. The API returns an error because MOCK integration is invalid.

C. The API triggers a Lambda function to process the request.

D. The API returns a predefined mock response without calling any backend.

Solution

1. Step 1: Understand MOCK integration

   MOCK integration returns a fixed response defined in API Gateway without backend calls.

2. Step 2: Analyze GET method on /books

   Since GET uses MOCK, the client receives the mock response directly.

3. Final Answer:

   The API returns a predefined mock response without calling any backend. -> Option D

4. Quick Check:

   MOCK integration = fixed response [OK]

Hint: MOCK returns fixed response, no backend called [OK]

Common Mistakes:

• Assuming MOCK calls database or Lambda
• Thinking MOCK integration causes errors
• Confusing MOCK with real backend integration

4. You created a POST method on resource /orders in API Gateway but get a 403 Forbidden error when testing. What is the most likely cause?

medium

A. The MOCK integration is missing a response template.

B. The resource path /orders is misspelled in the client request.

C. The method does not have permission to invoke the backend service.

D. The API Gateway does not support POST methods.

Solution

1. Step 1: Understand 403 Forbidden in API Gateway

   403 usually means permission denied to invoke backend or access resource.

2. Step 2: Check method permissions

   POST method likely lacks permission to call backend service, causing 403 error.

3. Final Answer:

   The method does not have permission to invoke the backend service. -> Option C

4. Quick Check:

   403 = permission denied [OK]

Hint: 403 means permission denied to backend [OK]

Common Mistakes:

• Assuming API Gateway disallows POST
• Blaming client path spelling without checking
• Thinking MOCK integration causes 403

5. You want to create a REST API with a resource /users that supports GET and POST methods. You start with MOCK integration for both methods to test. Later, you want GET to fetch data from a Lambda function and POST to store data in DynamoDB via Lambda. What is the best approach to achieve this?

hard

A. Create the API with MOCK integration first, then update GET and POST methods to use Lambda integration with proper permissions.

B. Create separate APIs for MOCK and Lambda integrations and switch clients between them.

C. Use MOCK integration permanently because it is simpler and faster.

D. Directly connect POST method to DynamoDB without Lambda and keep GET as MOCK.

Solution

1. Step 1: Start with MOCK integration for testing

   MOCK lets you test API behavior without backend, a good first step.

2. Step 2: Update methods to Lambda integration

   Later, replace MOCK with Lambda integration for GET and POST to connect real backend logic.

3. Step 3: Ensure permissions and backend setup

   Configure Lambda permissions and DynamoDB access properly for smooth operation.

4. Final Answer:

   Create the API with MOCK integration first, then update GET and POST methods to use Lambda integration with proper permissions. -> Option A

5. Quick Check:

   Start MOCK, then switch to Lambda integration [OK]

Hint: Test with MOCK, then switch methods to Lambda integration [OK]

Common Mistakes:

• Trying to use MOCK and Lambda in separate APIs
• Keeping MOCK integration permanently
• Connecting POST directly to DynamoDB without Lambda