Why Error response structure in Rest API? - Purpose & Use Cases

The Big Idea

What if your app could instantly tell users exactly what went wrong and how to fix it?

The Scenario

Imagine you are building a website that talks to a server. When something goes wrong, like a missing file or wrong password, the server just sends back a confusing message or nothing at all.

You have to guess what happened and how to fix it.

The Problem

Without a clear error response structure, your app gets stuck trying to understand what went wrong.

This makes debugging slow and frustrating.

Users see unclear messages or no feedback, causing bad experience.

The Solution

Using a well-defined error response structure means the server sends back clear, consistent messages about what failed and why.

This helps your app handle errors smartly and show helpful info to users.

Before vs After

✗ Before

{ "error": "Something went wrong" }

✓ After

{ "error": { "code": 404, "message": "File not found", "details": "The requested image.jpg does not exist." } }

What It Enables

It enables your app to respond clearly and quickly to problems, improving user trust and making debugging easier.

Real Life Example

When a user tries to log in with a wrong password, the server sends back a structured error explaining the issue, so the app can show a friendly message like "Password incorrect, please try again." instead of a vague failure.

Key Takeaways

Manual error handling is confusing and slow.

Structured error responses give clear, consistent info.

This improves user experience and speeds up fixing problems.

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