Error response structure in Rest API - Step-by-Step Execution

Concept Flow - Error response structure

Client sends request

↓

Server processes request

↓

Error occurs?

No→Send success response

Yes↓

Create error response

↓

Send error response to client

This flow shows how a server handles a client request and sends an error response if something goes wrong.

Execution Sample

Rest API

{
  "error": {
    "code": 404,
    "message": "Resource not found",
    "details": "The requested item does not exist."
  }
}

This JSON shows a typical error response with code, message, and details.

Execution Table

Step	Action	Condition	Result	Response Sent
1	Receive client request	N/A	Request received	No
2	Process request	N/A	Check resource availability	No
3	Resource found?	No	Prepare error response	No
4	Create error JSON	N/A	{"error":{"code":404,"message":"Resource not found","details":"The requested item does not exist."}}	No
5	Send response	N/A	Error response sent to client	Yes

💡 Error response sent because resource was not found

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
request	None	Received	Received	Received	Received
resource_found	Undefined	Undefined	False	False	False
error_response	None	None	None	{"error":{"code":404,"message":"Resource not found","details":"The requested item does not exist."}}	{"error":{"code":404,"message":"Resource not found","details":"The requested item does not exist."}}

Key Moments - 2 Insights

Why do we include both 'code' and 'message' in the error response?

The 'code' gives a quick numeric identifier for the error (like 404), while the 'message' explains it in words. This helps both machines and humans understand the problem, as shown in step 4 of the execution_table.

What is the purpose of the 'details' field in the error response?

The 'details' field gives extra information to help the client understand the error better. It is optional but useful for debugging, as seen in the error_response variable in variable_tracker after step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'resource_found' after step 3?

A True

B False

C Undefined

D None

💡 Hint

Check the variable_tracker row for 'resource_found' after step 3

At which step is the error JSON created?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for step 4

If the resource was found, what would happen instead of sending the error response?

A Send success response

B Send error response anyway

C Ignore the request

D Restart the server

💡 Hint

Refer to the concept_flow where 'Error occurs?' leads to different paths

Concept Snapshot

Error response structure:
- Use a JSON object with an 'error' key
- Include 'code' (number), 'message' (string), and optional 'details'
- Sent when server cannot fulfill request
- Helps client understand what went wrong
- Follow consistent format for easy parsing

Full Transcript

This visual execution shows how a server handles a client request and sends an error response if the requested resource is not found. The server receives the request, checks if the resource exists, and when it does not, creates a JSON error response with code 404, a message, and details. This error response is then sent back to the client. Variables like 'resource_found' and 'error_response' track the state during execution. Key points include why both code and message are included and the role of details. The quiz questions help reinforce understanding of the steps and variables involved.

Practice

1. What is the main purpose of an error response structure in a REST API?

easy

A. To clearly communicate what went wrong during a request

B. To speed up the API response time

C. To store user data securely

D. To format the successful response data

Solution

1. Step 1: Understand the role of error responses

   Error responses are sent when something goes wrong to inform the user or client about the issue.

2. Step 2: Identify the purpose of the error structure

   The structure helps communicate the problem clearly, usually with a code and message.

3. Final Answer:

   To clearly communicate what went wrong during a request -> Option A

4. Quick Check:

   Error response = clear problem message [OK]

Hint: Error responses explain problems clearly to users [OK]

Common Mistakes:

• Thinking error responses speed up API
• Confusing error response with data storage
• Assuming error response formats success data

2. Which of the following is the correct JSON syntax for a simple error response with code 404 and message "Not Found"?

easy

A. {"error": {code: 404, message: "Not Found"}}

B. {"error": {"code": 404, "message": "Not Found"}}

C. {"error": {"code": "404", "message": Not Found}}

D. {"error": {"code": 404, message: Not Found}}

Solution

1. Step 1: Check JSON key and string syntax

   Keys and string values must be in double quotes. Numbers like 404 do not need quotes.

2. Step 2: Identify the correct option

   {"error": {"code": 404, "message": "Not Found"}} uses correct quotes for keys and strings, and number 404 without quotes.

3. Final Answer:

   {"error": {"code": 404, "message": "Not Found"}} -> Option B

4. Quick Check:

   JSON keys and strings need double quotes [OK]

Hint: Use double quotes for keys and string values in JSON [OK]

Common Mistakes:

• Missing quotes around keys
• Using quotes around numbers
• Not quoting string values

3. Given this error response JSON:

{"error": {"code": 401, "message": "Unauthorized access"}}

What is the value of the message field?

medium

A. "error"

B. 401

C. null

D. "Unauthorized access"

Solution

1. Step 1: Locate the message field in the JSON

   The message field is inside the error object and has the value "Unauthorized access".

2. Step 2: Confirm the value type

   The value is a string, so it includes the quotes in JSON representation.

3. Final Answer:

   "Unauthorized access" -> Option D

4. Quick Check:

   message field value = "Unauthorized access" [OK]

Hint: Look inside error object for message value [OK]

Common Mistakes:

• Confusing code with message
• Selecting the key name instead of value
• Assuming null when field exists

4. You receive this error response from your API:

{"error": {"code": "400", "message": "Bad Request"}}

Why might this cause problems in your client code expecting code as a number?

medium

A. Because the error key is misspelled

B. Because the message is missing

C. Because the code is a string, not a number, causing type errors

D. Because the JSON is invalid

Solution

1. Step 1: Identify the data type of code field

   The code field is given as a string "400" instead of a number 400.

2. Step 2: Understand client expectations

   If client expects a number, receiving a string can cause type errors or failed comparisons.

3. Final Answer:

   Because the code is a string, not a number, causing type errors -> Option C

4. Quick Check:

   Type mismatch in code field causes errors [OK]

Hint: Check if code is number, not string, to avoid type errors [OK]

Common Mistakes:

• Ignoring type differences
• Assuming message is missing
• Thinking JSON is invalid

5. You want to design an error response structure that includes an error code, a message, and optionally a list of field errors for validation issues. Which JSON structure below correctly supports this?

hard

A. {"error": {"code": 422, "message": "Validation failed", "fields": [{"field": "email", "error": "Invalid format"}]}}

B. {"error": {"code": 422, "message": "Validation failed", "fields": "email: Invalid format"}}

C. {"error": {"code": 422, "message": "Validation failed", "fields": {"email": "Invalid format"}}}

D. {"error": {"code": 422, "message": "Validation failed", "fields": ["email", "Invalid format"]}}

Solution

1. Step 1: Understand the need for multiple field errors

   We want a list of objects, each with a field name and its error message.

2. Step 2: Check each option's fields format

   {"error": {"code": 422, "message": "Validation failed", "fields": [{"field": "email", "error": "Invalid format"}]}} uses an array of objects with field and error keys, which is clear and extensible.

3. Step 3: Identify why others are incorrect

   {"error": {"code": 422, "message": "Validation failed", "fields": "email: Invalid format"}} uses a string instead of structured data; {"error": {"code": 422, "message": "Validation failed", "fields": {"email": "Invalid format"}}} uses an object but not a list; {"error": {"code": 422, "message": "Validation failed", "fields": ["email", "Invalid format"]}} uses a list mixing field and message without keys.

4. Final Answer:

   {"error": {"code": 422, "message": "Validation failed", "fields": [{"field": "email", "error": "Invalid format"}]}} -> Option A

5. Quick Check:

   Use array of objects for detailed field errors [OK]

Hint: Use array of objects for multiple field errors [OK]

Common Mistakes:

• Using plain strings instead of structured objects
• Mixing field names and messages in arrays without keys
• Using object instead of list for multiple errors