Why Request and response mapping in AWS? - Purpose & Use Cases

The Big Idea

What if your app could talk to any service without you rewriting data every time?

The Scenario

Imagine you have a web app that talks to many different services, each expecting data in a special format. You try to connect them by hand, changing data formats manually every time a request or response happens.

The Problem

Doing this by hand is slow and confusing. You might forget to change something or make mistakes that break your app. It's like translating languages without a dictionary, causing delays and errors.

The Solution

Request and response mapping lets you set clear rules to automatically change data formats between your app and services. This way, everything talks smoothly without manual fixes, saving time and avoiding errors.

Before vs After

✗ Before

if request.type == 'json':
  data = parse_json(request.body)
  formatted = format_for_service(data)
  response = call_service(formatted)
  return parse_service_response(response)

✓ After

mapping_template = load_mapping()
response = api_gateway.invoke(request, mapping_template)
return response

What It Enables

It enables seamless communication between different systems by automatically transforming data formats as needed.

Real Life Example

When a mobile app sends data in JSON but the backend service only understands XML, request and response mapping converts JSON to XML and back without extra coding.

Key Takeaways

Manual data format changes are slow and error-prone.

Mapping automates data transformation between systems.

This makes integrations faster, reliable, and easier to manage.

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