Request and response mapping in AWS - Time & Space Complexity

Time Complexity: Request and response mapping

O(n)

Understanding Time Complexity

When using request and response mapping in AWS, it is important to understand how the number of mapping operations affects performance.

We want to know how the time to process mappings grows as the number of requests or mapping rules increases.

Scenario Under Consideration

Analyze the time complexity of the following mapping operations.

// Example of request and response mapping in API Gateway
{
  "requestTemplates": {
    "application/json": "mapping logic for request"
  },
  "responseTemplates": {
    "application/json": "mapping logic for response"
  }
}
// Each request triggers these mappings before forwarding or returning data

This sequence shows how each incoming request and outgoing response is transformed by mapping templates.

Identify Repeating Operations

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

• Primary operation: Applying request and response mapping templates for each API call.
• How many times: Once per request and once per response, repeating for every API call.

How Execution Grows With Input

Each API call requires processing the mapping templates once for the request and once for the response.

Input Size (n)	Approx. API Calls/Operations
10	20 mapping operations (10 requests + 10 responses)
100	200 mapping operations
1000	2000 mapping operations

Pattern observation: The number of mapping operations grows directly with the number of API calls.

Final Time Complexity

Time Complexity: O(n)

This means the time to process mappings grows linearly with the number of API calls.

Common Mistake

[X] Wrong: "Mapping templates run once and then apply to all requests without extra cost."

[OK] Correct: Each request and response is processed separately, so mapping happens every time, adding cost per call.

Interview Connect

Understanding how request and response mappings scale helps you design APIs that perform well as traffic grows.

Self-Check

"What if we added caching to reduce mapping operations? How would the time complexity change?"

Practice

1. What is the main purpose of request and response mapping in AWS API Gateway?

easy

A. To encrypt data during transmission

B. To change data formats between client and backend

C. To monitor user activity on the website

D. To store data permanently in the cloud

Solution

1. Step 1: Understand the role of mapping templates

   Mapping templates in API Gateway transform data formats between client requests and backend responses.

2. Step 2: Identify the main purpose

   This transformation allows different systems to communicate smoothly by renaming, adding, or removing fields.

3. Final Answer:

   To change data formats between client and backend -> Option B

4. Quick Check:

   Mapping templates = data format change [OK]

Hint: Mapping templates transform data formats between client and backend [OK]

Common Mistakes:

• Confusing mapping with data storage
• Thinking mapping encrypts data
• Assuming mapping monitors activity

2. Which of the following is the correct syntax to access a JSON field named userId in a request mapping template?

easy

A. $input.path('$.userId')

B. $input.json('userId')

C. $input.get('userId')

D. $input.body('userId')

Solution

1. Step 1: Recall JSON path syntax in mapping templates

   The correct way to access a JSON field is using $input.path('$.fieldName').

2. Step 2: Match the syntax to the field userId

   Using $input.path('$.userId') correctly accesses the userId field.

3. Final Answer:

   $input.path('$.userId') -> Option A

4. Quick Check:

   JSON field access = $input.path('$.field') [OK]

Hint: Use $input.path('$.fieldName') to access JSON fields [OK]

Common Mistakes:

• Using incorrect method names like json or get
• Missing the '$.' prefix in JSON path
• Confusing body access with path access

3. Given this request mapping template:

{
  "user": "$input.path('$.username')",
  "id": "$input.path('$.userId')"
}

What will be the transformed request if the client sends:

{"username": "alice", "userId": "123"}

medium

A. {"user": "$.username", "id": "$.userId"}

B. {"username": "alice", "userId": "123"}

C. {"user": "alice", "id": "123"}

D. {"user": null, "id": null}

Solution

1. Step 1: Understand the mapping template fields

   The template maps user to $.username and id to $.userId.

2. Step 2: Apply the client JSON values

   Client sends username as "alice" and userId as "123", so these replace the template placeholders.

3. Final Answer:

   {"user": "alice", "id": "123"} -> Option C

4. Quick Check:

   Template fields replaced by client values [OK]

Hint: Mapping replaces template fields with client JSON values [OK]

Common Mistakes:

• Confusing template keys with client keys
• Leaving placeholders as literal strings
• Assuming null values when fields exist

4. You have this response mapping template:

{
  "message": "$input.path('$.msg')",
  "status": "$input.path('$.code')"
}

But the backend returns:

{"message": "Success", "code": 200}

What is the main issue causing the mapping to fail?

medium

A. The template uses wrong JSON paths not matching backend keys

B. The backend response is not valid JSON

C. The template syntax is missing quotes around keys

D. The backend response keys are case-insensitive

Solution

1. Step 1: Compare template paths with backend keys

   The template expects msg and code, but backend returns message and code.

2. Step 2: Identify mismatch causing failure

   Since msg does not exist in backend response, mapping fails for that field.

3. Final Answer:

   The template uses wrong JSON paths not matching backend keys -> Option A

4. Quick Check:

   Template paths must match backend keys exactly [OK]

Hint: Ensure template JSON paths match backend response keys exactly [OK]

Common Mistakes:

• Assuming backend keys are case-insensitive
• Thinking syntax errors cause this issue
• Ignoring key name mismatches

5. You want to add a new field requestTime with the current timestamp to every request sent to your backend using request mapping. Which mapping template snippet correctly adds this field?

hard

A. {
"user": "$input.path('$.user')",
"requestTime": "$context.stage"
}

B. {
"user": "$input.path('$.user')",
"requestTime": "$input.requestTime"
}

C. {
"user": "$input.path('$.user')",
"requestTime": "$stageVariables.requestTime"
}

D. {
"user": "$input.path('$.user')",
"requestTime": "$context.requestTime"
}

Solution

1. Step 1: Identify how to get current request time

   In API Gateway mapping templates, $context.requestTime provides the current request timestamp.

2. Step 2: Check each option for correct usage

   { "user": "$input.path('$.user')", "requestTime": "$context.requestTime" } uses $context.requestTime correctly; others use invalid or unrelated variables.

3. Final Answer:

   { "user": "$input.path('$.user')", "requestTime": "$context.requestTime" } -> Option D

4. Quick Check:

   Use $context.requestTime for current timestamp [OK]

Hint: Use $context.requestTime to add current timestamp in mapping [OK]

Common Mistakes:

• Using $input.requestTime which doesn't exist
• Confusing stage variables with request time
• Using unrelated context variables