Response envelope patterns in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this JSON response envelope?

Consider this API response envelope pattern:

{
  "status": "success",
  "data": {
    "user": {
      "id": 101,
      "name": "Alice"
    }
  },
  "error": null
}

What will be the value of error in this response?

A "null" (string)

B An empty object {}

C An empty string ""

D null (JSON null value)

💡 Hint

Look carefully at the value type of error in the JSON.

The error field is set to null which is a JSON null value, not a string or empty object.

🧠 Conceptual

intermediate

Why use a response envelope in REST APIs?

Which of the following is the main reason to use a response envelope pattern in REST APIs?

A To separate metadata like status and errors from the actual data payload

B To make the response smaller by removing metadata

C To always return HTTP status 200 and put error info inside the envelope

D To force clients to parse XML instead of JSON

💡 Hint

Think about how metadata and data are organized in the response.

Response envelopes separate metadata (status, errors) from the main data, making responses consistent and easier to handle.

🔧 Debug

advanced

Identify the error in this response envelope example

Here is a JSON response envelope from an API:

{
  "status": "error",
  "data": null,
  "error": {
    "code": 404,
    "message": "User not found"
  }
}

What is wrong with this response if the HTTP status code is also 404?

A The <code>data</code> field should not be null when there is an error

B The <code>status</code> field should be "success" even if HTTP status is 404

C There is no error; this is a correct pattern

D The HTTP status code should be 200 when using response envelopes

💡 Hint

Think about how error information is represented in the envelope and HTTP status.

It is valid to return HTTP 404 with an error envelope showing the error details and data as null.

📝 Syntax

advanced

Which JSON response envelope is syntactically correct?

Choose the syntactically correct JSON response envelope:

A { "status": "success", "data": { "id": 1, "name": "Bob" }, "error": null }

B { "status": "success", "data": { "id": 1, "name": "Bob" }, "error": }

C { "status": "success", "data": { "id": 1, "name": "Bob" }, "error": undefined }

D { "status": "success", "data": { "id": 1, "name": "Bob" }, "error": None }

💡 Hint

Remember JSON syntax rules for null and values.

Only option A uses valid JSON syntax with null for no error. Options A, C, and D are invalid JSON.

🚀 Application

expert

How many items are in the 'data' field of this response envelope?

Given this JSON response envelope:

{
  "status": "success",
  "data": {
    "users": [
      {"id": 1, "name": "Anna"},
      {"id": 2, "name": "Ben"},
      {"id": 3, "name": "Cara"}
    ],
    "count": 3
  },
  "error": null
}

How many user objects are inside the data.users array?

A 2

B 3

C 4

D 0

💡 Hint

Count the number of objects inside the users array.

The users array contains exactly 3 user objects.

Practice

1. What is the main purpose of using a response envelope in REST APIs?

easy

A. To increase the size of the response for security

B. To wrap the actual data with status and messages for clarity

C. To hide the data from the client

D. To make the API slower intentionally

Solution

1. Step 1: Understand what a response envelope is

   A response envelope is a structure that wraps the main data with extra information like status and messages.

2. Step 2: Identify the purpose of wrapping data

   This wrapping helps clients quickly understand if the request succeeded or failed and provides useful messages.

3. Final Answer:

   To wrap the actual data with status and messages for clarity -> Option B

4. Quick Check:

   Response envelope = Wrap data with status and messages [OK]

Hint: Response envelopes add status and messages around data [OK]

Common Mistakes:

• Thinking response envelopes hide data
• Believing they slow down the API on purpose
• Confusing response envelopes with security features

2. Which of the following is the correct JSON structure for a simple response envelope?

easy

A. {"status": "success", "data": {"id": 1, "name": "Alice"}}

B. {"data": {"id": 1, "name": "Alice"}, "error": null}

C. {"result": {"id": 1, "name": "Alice"}}

D. {"message": "success", "payload": {"id": 1, "name": "Alice"}}

Solution

1. Step 1: Identify the typical keys in a response envelope

   Common keys include "status" for success/failure and "data" for the actual content.

2. Step 2: Check each option for correct keys and structure

   {"status": "success", "data": {"id": 1, "name": "Alice"}} uses "status" and "data" correctly. Others use different or missing keys.

3. Final Answer:

   {"status": "success", "data": {"id": 1, "name": "Alice"}} -> Option A

4. Quick Check:

   Correct keys = status + data [OK]

Hint: Look for 'status' and 'data' keys in JSON [OK]

Common Mistakes:

• Using 'result' or 'payload' instead of 'data'
• Missing the 'status' key
• Confusing 'error' with 'status'

3. Given this response envelope JSON:

{"status": "error", "message": "Not found", "data": null}

What should the client understand from this response?

medium

A. The request succeeded and data is available

B. The server returned invalid JSON

C. The request succeeded but data is empty

D. The request failed and no data is returned

Solution

1. Step 1: Analyze the 'status' field

   The status is "error", indicating the request did not succeed.

2. Step 2: Check the 'message' and 'data' fields

   The message says "Not found" and data is null, meaning no data was returned due to an error.

3. Final Answer:

   The request failed and no data is returned -> Option D

4. Quick Check:

   Status 'error' + null data = failure [OK]

Hint: Check 'status' first to know success or failure [OK]

Common Mistakes:

• Assuming 'error' means success
• Ignoring the 'message' field
• Thinking null data means empty success

4. You have this response envelope:

{"status": "success", "data": {"id": 5}}

What is wrong with this response?

medium

A. Missing closing brace for JSON object

B. Missing 'message' field in the envelope

C. Data should be an array, not an object

D. Status should be 'ok' instead of 'success'

Solution

1. Step 1: Check JSON syntax

   The JSON string ends after "id": 5 without closing the outer object with a brace.

2. Step 2: Validate required fields

   While 'message' is optional and 'data' can be an object, the missing brace is a syntax error.

3. Final Answer:

   Missing closing brace for JSON object -> Option A

4. Quick Check:

   JSON must have matching braces [OK]

Hint: Always check JSON braces for completeness [OK]

Common Mistakes:

• Assuming 'message' is mandatory
• Thinking 'data' must be an array
• Confusing status values

5. You want to design a response envelope that includes:
- A status code (number)
- A success boolean
- A message string
- The actual data

Which JSON structure best fits this requirement?

hard

A. {"result": {"code": 200, "message": "OK"}, "payload": {"user": "Bob"}}

B. {"status": "success", "data": {"user": "Bob"}}

C. {"code": 200, "success": true, "message": "OK", "data": {"user": "Bob"}}

D. {"success": "true", "code": "200", "msg": "OK", "data": {"user": "Bob"}}

Solution

1. Step 1: Match required fields with options

   Required fields are numeric status code, boolean success, message string, and data object.

2. Step 2: Check each option for correct types and keys

   {"code": 200, "success": true, "message": "OK", "data": {"user": "Bob"}} uses 'code' as number, 'success' as boolean, 'message' as string, and 'data' correctly. Others miss types or keys.

3. Final Answer:

   {"code": 200, "success": true, "message": "OK", "data": {"user": "Bob"}} -> Option C

4. Quick Check:

   Correct keys and types = {"code": 200, "success": true, "message": "OK", "data": {"user": "Bob"}} [OK]

Hint: Check data types match requirements exactly [OK]

Common Mistakes:

• Using strings instead of boolean or number
• Missing some required fields
• Using inconsistent key names