Nested error reporting in Rest API - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When reporting errors in a nested structure, it is important to understand how the time to process errors grows as the depth and number of errors increase.
We want to know how the work needed to collect and report all nested errors changes as the input grows.
Analyze the time complexity of the following code snippet.
function reportErrors(errors) {
let allMessages = [];
for (const error of errors) {
allMessages.push(error.message);
if (error.nested) {
allMessages = allMessages.concat(reportErrors(error.nested));
}
}
return allMessages;
}
This code collects error messages from a list of errors, including any nested errors recursively.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each error and recursively processing nested errors.
- How many times: Once for each error and all its nested errors, visiting every error exactly once.
As the number of errors and their nested errors grows, the total work grows with the total count of all errors.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 loops and recursive calls |
| 100 | About 100 loops and recursive calls |
| 1000 | About 1000 loops and recursive calls |
Pattern observation: The work grows roughly in direct proportion to the total number of errors, including nested ones.
Time Complexity: O(n)
This means the time to report errors grows linearly with the total number of errors and nested errors combined.
[X] Wrong: "Nested errors cause the time to grow exponentially because of recursion."
[OK] Correct: Each error is processed only once, so the total work adds up linearly, not exponentially.
Understanding how recursive error reporting scales helps you explain how your code handles complex data structures efficiently.
"What if we changed the code to process nested errors twice each time they appear? How would the time complexity change?"
Practice
What is the main purpose of nested error reporting in REST APIs?
Solution
Step 1: Understand error reporting basics
Error reporting helps identify problems in API requests or responses.Step 2: Recognize nested error reporting role
Nested error reporting shows errors inside complex or nested data structures clearly.Final Answer:
To show detailed errors inside nested data clearly -> Option AQuick Check:
Nested error reporting = detailed nested errors [OK]
- Thinking nested errors hide problems
- Confusing error reporting with encryption
- Assuming it speeds up API responses
Which JSON structure correctly represents a nested error for a REST API response?
{
"error": {
"message": "Invalid input",
"details": {
"field": "email",
"error": "Invalid format"
}
}
}Solution
Step 1: Identify nested JSON error format
Nested error reporting uses objects inside objects to show details clearly.Step 2: Match the correct JSON structure
{ "error": { "message": "Invalid input", "details": { "field": "email", "error": "Invalid format" } } } shows an error object with a message and nested details object with field and error.Final Answer:
{ "error": { "message": "Invalid input", "details": { "field": "email", "error": "Invalid format" } } } -> Option DQuick Check:
Nested JSON error = { "error": { "message": "Invalid input", "details": { "field": "email", "error": "Invalid format" } } } [OK]
- Using arrays instead of objects for nested errors
- Missing nested details object
- Flattening error info without nesting
Given this REST API error response JSON, what is the error message for the password field?
{
"error": {
"message": "Validation failed",
"fields": {
"email": "Invalid format",
"password": "Too short"
}
}
}Solution
Step 1: Locate the password field in JSON
The password error is inside error.fields.password.Step 2: Read the error message for password
The value is "Too short", indicating the password error.Final Answer:
Too short -> Option CQuick Check:
password error message = "Too short" [OK]
- Choosing top-level message instead of field error
- Confusing email error with password error
- Ignoring nested fields object
Identify the error in this nested error JSON response:
{
"error": {
"message": "Invalid data",
"details": [
{ "field": "username", "error": "Required" },
{ "field": "age", "error": 25 }
]
}
}Solution
Step 1: Check error value types in details array
Each error value should be a descriptive string, not a number.Step 2: Identify incorrect error value
The 'age' field has error value 25 (number), which is incorrect.Final Answer:
The 'error' value for 'age' should be a string, not a number -> Option AQuick Check:
Error values must be strings [OK]
- Ignoring type mismatch in error values
- Thinking details must be string instead of array
- Missing the message key
You want to design a nested error response for a REST API that validates a user profile with nested address fields. Which JSON structure best represents errors for both the email and nested address.zipcode fields?
Solution
Step 1: Understand nested error reporting for nested fields
Nested fields like address.zipcode should be represented as nested objects.Step 2: Evaluate JSON options for nested structure
{ "error": { "fields": { "email": "Invalid", "address": { "zipcode": "Missing" } } } } uses a 'fields' object with 'email' error and nested 'address' object containing 'zipcode' error.Final Answer:
{ "error": { "fields": { "email": "Invalid", "address": { "zipcode": "Missing" } } } } -> Option BQuick Check:
Nested fields use nested objects = { "error": { "fields": { "email": "Invalid", "address": { "zipcode": "Missing" } } } } [OK]
- Using dot notation keys instead of nested objects
- Flattening nested errors into arrays
- Combining all errors into one string
