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.
Why this answer
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.
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.