Error response structure in Rest API - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When a REST API sends an error response, it usually builds a structured message to explain what went wrong.
We want to understand how the time to create this error message changes as the error details grow.
Analyze the time complexity of the following code snippet.
function createErrorResponse(errors) {
return {
status: "error",
errors: errors.map(err => ({ code: err.code, message: err.message }))
};
}
This code builds an error response object by mapping over a list of error details.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Mapping over the errors array to create a new array of error objects.
- How many times: Once for each error in the input list.
Explain the growth pattern intuitively.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 map operations |
| 100 | 100 map operations |
| 1000 | 1000 map operations |
Pattern observation: The number of operations grows directly with the number of errors; doubling errors doubles work.
Time Complexity: O(n)
This means the time to build the error response grows in a straight line with the number of errors.
[X] Wrong: "Creating the error response takes the same time no matter how many errors there are."
[OK] Correct: Each error detail must be processed, so more errors mean more work and more time.
Understanding how error response time grows helps you design APIs that handle many errors efficiently and predict performance.
"What if the error response included nested details for each error? How would the time complexity change?"
Practice
Solution
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.Step 2: Identify the purpose of the error structure
The structure helps communicate the problem clearly, usually with a code and message.Final Answer:
To clearly communicate what went wrong during a request -> Option AQuick Check:
Error response = clear problem message [OK]
- Thinking error responses speed up API
- Confusing error response with data storage
- Assuming error response formats success data
Solution
Step 1: Check JSON key and string syntax
Keys and string values must be in double quotes. Numbers like 404 do not need quotes.Step 2: Identify the correct option
{"error": {"code": 404, "message": "Not Found"}} uses correct quotes for keys and strings, and number 404 without quotes.Final Answer:
{"error": {"code": 404, "message": "Not Found"}} -> Option BQuick Check:
JSON keys and strings need double quotes [OK]
- Missing quotes around keys
- Using quotes around numbers
- Not quoting string values
{"error": {"code": 401, "message": "Unauthorized access"}}What is the value of the
message field?Solution
Step 1: Locate the message field in the JSON
The message field is inside the error object and has the value "Unauthorized access".Step 2: Confirm the value type
The value is a string, so it includes the quotes in JSON representation.Final Answer:
"Unauthorized access" -> Option DQuick Check:
message field value = "Unauthorized access" [OK]
- Confusing code with message
- Selecting the key name instead of value
- Assuming null when field exists
{"error": {"code": "400", "message": "Bad Request"}}Why might this cause problems in your client code expecting
code as a number?Solution
Step 1: Identify the data type of code field
The code field is given as a string "400" instead of a number 400.Step 2: Understand client expectations
If client expects a number, receiving a string can cause type errors or failed comparisons.Final Answer:
Because the code is a string, not a number, causing type errors -> Option CQuick Check:
Type mismatch in code field causes errors [OK]
- Ignoring type differences
- Assuming message is missing
- Thinking JSON is invalid
Solution
Step 1: Understand the need for multiple field errors
We want a list of objects, each with a field name and its error message.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.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.Final Answer:
{"error": {"code": 422, "message": "Validation failed", "fields": [{"field": "email", "error": "Invalid format"}]}} -> Option AQuick Check:
Use array of objects for detailed field errors [OK]
- Using plain strings instead of structured objects
- Mixing field names and messages in arrays without keys
- Using object instead of list for multiple errors
