Partial success handling in Rest API - Time & Space Complexity
When handling partial success in REST APIs, some operations succeed while others fail. We want to understand how the time to process these results grows as the number of operations increases.
How does the processing time change when more items are involved?
Analyze the time complexity of the following code snippet.
// Assume responses is a list of results from multiple API calls
for (let i = 0; i < responses.length; i++) {
if (responses[i].status === 'success') {
processSuccess(responses[i].data);
} else {
processFailure(responses[i].error);
}
}
This code loops through each response and processes it based on success or failure.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each response item once.
- How many times: Exactly once per response, so as many times as the number of responses.
As the number of responses grows, the code processes each one individually.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 processing steps |
| 100 | 100 processing steps |
| 1000 | 1000 processing steps |
Pattern observation: The work grows directly with the number of responses; doubling responses doubles the work.
Time Complexity: O(n)
This means the time to handle partial success grows linearly with the number of responses.
[X] Wrong: "Partial success handling is faster because it skips failed items."
[OK] Correct: Even failed items must be checked and processed, so the code still touches every item once.
Understanding how partial success handling scales helps you explain API response processing clearly and confidently in interviews.
"What if processSuccess or processFailure themselves loop over data inside each response? How would that affect the time complexity?"
Practice
HTTP 207 Multi-Status indicate in REST API partial success handling?Solution
Step 1: Understand HTTP 207 Multi-Status meaning
HTTP 207 is used to report multiple status codes for different parts of a single request.Step 2: Relate to partial success handling
This status code indicates that some parts succeeded and others failed, providing detailed results.Final Answer:
Some parts of the request succeeded while others failed -> Option AQuick Check:
HTTP 207 = Partial success [OK]
- Confusing 207 with 200 OK
- Thinking 207 means full failure
- Assuming 207 is a redirect status
Solution
Step 1: Identify correct HTTP status for partial success
HTTP 207 Multi-Status is designed to show multiple results in one response.Step 2: Confirm response format
Using JSON to detail which parts succeeded or failed is the standard approach.Final Answer:
HTTP 207 with JSON detailing success and failure -> Option CQuick Check:
207 + JSON = Partial success response [OK]
- Using 200 OK without details
- Returning 404 for partial success
- Sending server error 500 instead of partial status
{
"responses": [
{"id": 1, "status": "success"},
{"id": 2, "status": "failure", "error": "Invalid data"},
{"id": 3, "status": "success"}
]
}Solution
Step 1: Locate item with ID 3 in JSON
Item with ID 3 has "status": "success" in the responses array.Step 2: Interpret the status value
The status "success" means the operation for item 3 succeeded.Final Answer:
Success -> Option BQuick Check:
ID 3 status = success [OK]
- Confusing failure of other items with this one
- Assuming missing error means failure
- Ignoring the status field
HTTP/1.1 207 Multi-Status
{
"results": [
{"item": "A", "status": "success"},
{"item": "B", "status": "fail", "error": "Timeout"}
]
}
What is the main issue in this response?Solution
Step 1: Check HTTP status code usage
HTTP 207 Multi-Status is correct for partial success.Step 2: Verify status field values
Common practice uses "success" and "failure" or "error"; "fail" is inconsistent and may cause confusion.Final Answer:
The status value "fail" should be "failure" or "error" -> Option DQuick Check:
Status values must be consistent and clear [OK]
- Thinking 207 is wrong here
- Ignoring inconsistent status wording
- Assuming JSON is invalid without checking
Solution
Step 1: Identify the need for partial success reporting
Since some updates succeed and others fail, the response must show both results clearly.Step 2: Choose appropriate HTTP status and response format
HTTP 207 Multi-Status with detailed JSON per user update is the best practice to communicate partial success.Final Answer:
Return HTTP 207 with a JSON array showing each user's update status and error if any -> Option AQuick Check:
207 + detailed JSON = clear partial success [OK]
- Ignoring failed updates in response
- Using 200 OK without details
- Returning generic errors instead of per-item status
Ready to prove it?
Pass the test and this pattern moves unknown
