Understanding and Using APIs →hardMultiple Select

200-901 Understanding and Using APIs Practice Question

A developer is integrating with a REST API that returns JSON error responses. The team needs to handle failures robustly in code. Which TWO practices are appropriate when processing API responses? (Choose two.)

⚠ Common exam trap

The trap here is assuming that a body which parses as JSON proves success, when error responses frequently return valid JSON with non-2xx status codes.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Check the HTTP status code before attempting to parse the response body.

Robust API clients branch on the HTTP status code first, then guard JSON parsing by checking the content type and body presence. This ordering prevents schema mismatches when error payloads differ from success payloads and avoids parser exceptions on empty or non-JSON responses. These two practices together form a reliable foundation for error handling in any REST integration.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Retry every failed request immediately in a tight loop until it succeeds.
Why it's wrong here
Immediate tight-loop retries can amplify load during outages and may violate rate limits, triggering 429 responses. Retries should be limited, spaced with backoff, and applied only to transient errors such as 5xx or 429. Retrying client errors like 400 or 401 will never succeed without changing the request.
✗
Ignore the status code and rely solely on whether the body parses as valid JSON.
Why it's wrong here
Many APIs return valid JSON for error conditions, so successful parsing does not imply success. A 400 response often contains a well-formed JSON error object. Ignoring the status code would cause the application to treat failures as successes, leading to silent data corruption and confusing downstream behavior.
✓
Check the HTTP status code before attempting to parse the response body.
Why this is correct
Status codes are the primary signal of success or failure in HTTP. Checking them first prevents the code from misinterpreting an error payload as valid data. For example, a 404 or 500 may return a different JSON shape than a 200, so branching on the status code avoids schema errors and lets the program route to error handling cleanly.
✗
Assume any response containing the word "error" in the body indicates a failure and raise an exception.
Why it's wrong here
String matching on the word "error" is unreliable. A successful response might include a field named "errorCount" set to zero, or an "errors" array that is empty. Deciding failure based on substring presence rather than status codes and documented schema leads to false positives and brittle integrations.
✓
Parse the response body as JSON only after confirming the content type and that the body is non-empty.
Why this is correct
Not every response has a JSON body. A 204 No Content or a 500 with an HTML error page would break a naive JSON parser. Verifying the Content-Type header and checking for a non-empty body before parsing prevents exceptions and ensures the code only attempts JSON decoding when the payload actually is JSON.

Go deeper

200-901 Understanding and Using APIs Practice Question

Why each option matters

Option-by-option breakdown

Related to this question