Error response format in Rest API - Time & Space Complexity
When a REST API sends an error response, it often builds a structured message. We want to understand how the time to create this error message changes as the error details grow.
How does the work to prepare the error response grow with the size of the error information?
Analyze the time complexity of the following code snippet.
function createErrorResponse(errors) {
const response = { status: "error", errors: [] };
for (const err of errors) {
response.errors.push({ code: err.code, message: err.message });
}
return response;
}
This code builds an error response object by looping over a list of error details and adding each to the response.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through the list of errors to add each error detail to the response.
- How many times: Once for each error in the input list.
As the number of errors increases, the code adds more items to the response one by one.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 additions to the errors array |
| 100 | About 100 additions to the errors array |
| 1000 | About 1000 additions to the errors array |
Pattern observation: The work grows directly with the number of errors; doubling errors doubles the work.
Time Complexity: O(n)
This means the time to create the error response grows in a straight line with the number of errors.
[X] Wrong: "Adding more errors won't affect the time much because it's just one response."
[OK] Correct: Each error detail is added one by one, so more errors mean more work and more time.
Understanding how error responses scale helps you design APIs that handle many errors efficiently and predict how your code behaves as input grows.
What if we changed the error list to a nested structure with sub-errors? How would the time complexity change?
Practice
Solution
Step 1: Understand the role of error responses
Error responses tell the client what problem happened when processing their request.Step 2: Identify the main goal
The main goal is to communicate the error clearly so the client can handle it properly.Final Answer:
To clearly communicate what went wrong during a request -> Option BQuick Check:
Error response purpose = clear communication [OK]
- Thinking error responses speed up API
- Confusing error format with encryption
- Assuming error responses store data
Solution
Step 1: Identify standard error response keys
Common keys include "error", "code", and "message" to describe the problem.Step 2: Check each option
{"error": {"code": 404, "message": "Not Found"}} uses "error" with "code" and "message" correctly in JSON format.Final Answer:
{"error": {"code": 404, "message": "Not Found"}} -> Option AQuick Check:
Standard error keys = code and message [OK]
- Confusing success response with error
- Using wrong key names like error_code
- Missing nested error object
{"error": {"code": 401, "message": "Unauthorized"}}What HTTP status code should the API return?
Solution
Step 1: Match error code to HTTP status
The error code 401 means "Unauthorized", which is an HTTP status code for authentication failure.Step 2: Confirm correct HTTP status
The API should return HTTP status 401 to match the error code in the response body.Final Answer:
401 -> Option AQuick Check:
Error code 401 = HTTP status 401 [OK]
- Returning 200 for error responses
- Confusing 401 with 404
- Using 500 for client errors
{"error": {"code": "403", "message": "Forbidden"}}But your client expects the code as an integer. What is the best fix?
Solution
Step 1: Identify data type mismatch
The code is a string "403" but the client expects an integer 403.Step 2: Fix the data type in the response
Change the code value from a string to an integer to match client expectations.Final Answer:
Change the code value to an integer 403 in the response -> Option CQuick Check:
Match data types for code field [OK]
- Removing important error fields
- Changing message instead of code type
- Leaving code as string when integer needed
Solution
Step 1: Check required fields in each option
We need code, message, and optional details inside a clear error object.Step 2: Evaluate each JSON structure
{"error": {"code": 400, "message": "Bad Request", "details": "Missing 'id' parameter"}} includes all three: code, message, and details nested inside "error".Final Answer:
{"error": {"code": 400, "message": "Bad Request", "details": "Missing 'id' parameter"}} -> Option DQuick Check:
Include code, message, and details in error object [OK]
- Omitting details field
- Using inconsistent key names
- Not nesting error info properly
Ready to prove it?
Pass the test and this pattern moves unknown
