4xx Status Code Distinctions
Fast recall
Quick revision
Core answer
400 Bad Request for a broad request error, 404 Not Found when the target is missing or deliberately hidden, 409 Conflict when the request clashes with the resource's current state, and 422 Unprocessable Content when the content type and syntax are valid but the instructions still cannot be processed.Interview-ready guide
Interview answer
These codes point to different places where a request can fail. 400 is about a broad problem with the request itself. 404 is about the target. 409 is about the target's current state. 422 is about validly formed content whose instructions cannot be processed. Choosing the code by that boundary is clearer than treating every client error as 400.
Use 400 Bad Request when the server cannot or will not process the request because it sees a client error. Broken JSON is the simplest example: the server cannot even read the intended object. Invalid message framing and deceptive routing also fit 400. If the real problem is an unsupported Content-Type, 415 Unsupported Media Type is more exact.
Use 404 Not Found when the target has no current representation, such as GET /orders/999. The code can also hide a forbidden resource when confirming its existence would leak information. A 404 does not say the target is gone forever; use 410 Gone when the server knows the removal is permanent and wants to say so.
Use 409 Conflict when the request makes sense but clashes with the resource's current state. An order that is already shipped cannot be moved back to draft, so the client may need to fetch the current order and choose another action. If an explicit If-Match condition failed, 412 Precondition Failed is the more precise response.
Use 422 Unprocessable Content when the server understands the content type, the syntax is correct, but the instructions cannot be processed. For example, a well-formed order containing quantity: 0 may receive 422 if the API uses that code for domain validation. The older name “Unprocessable Entity” is still common, but RFC 9110 calls it “Unprocessable Content.”
An API may use 400 for all validation errors, or reserve 422 for syntactically correct requests that fail field or business rules. Both approaches can work. The important part is to document one rule, return stable error details, and prefer a more specific HTTP code when it exactly matches the failure.
4xx Status Code Distinctions
Direct Answer
Use 400 Bad Request for a broad request error, 404 Not Found when the target is missing or deliberately hidden, 409 Conflict when the request clashes with the resource's current state, and 422 Unprocessable Content when the content type and syntax are valid but the instructions still cannot be processed.
Deep Dive & Architecture
A useful way to classify these failures is to ask which boundary stopped the request. The server first needs a usable HTTP message and a supported media type. It may then need to find a target resource. After that, an HTTP precondition, the resource's current state, or the meaning of the submitted instructions can still stop the operation.
Each boundary tells a different story. Broken JSON can produce 400, while an unsupported Content-Type has the more precise 415 response. An unknown order ID can produce 404 when that existing target is required. A failed If-Match condition maps to 412. A valid order that is already shipped can stop a move-to-draft request at 409. A new order with valid JSON but an impossible quantity can produce 422 under an API that reserves 422 for domain validation.
The diagram is a classification guide, not a universal execution pipeline. Some requests create a target instead of looking one up, and an API can discover checks in a different order. Use the most precise status for the actual failure, then add stable problem codes and field errors so the client can recover without comparing changing English messages.
Code Example
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
{
"type": "https://api.example.com/problems/invalid-order",
"title": "Order cannot be processed",
"status": 422,
"detail": "One or more order fields violate business rules.",
"errors": [{"field": "quantity", "code": "must_be_positive"}]
}
Check your understanding
Answer these without looking back at the article.
- When is 412 more precise than 409?
- Can 404 be used to conceal a forbidden resource?
- Why do APIs differ on 400 versus 422 for validation?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.