Client Error vs Server Error Classification
HTTP status codes in the `4xx` range generally indicate that the request cannot be fulfilled because of something attributable to the client request, while `5xx` codes indicate that the server failed to fulfill an otherwise acceptable request. Correct classification helps API clients choose appropriate fixes, retries, and user-facing messages.
A `4xx` response means the server received and understood the request but considers the request invalid, unauthorized, forbidden, missing a required resource, or otherwise unsuitable to process. Common examples include `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, and `409 Conflict`.
A `5xx` response indicates a failure while the server is processing a request. Examples include `500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable`, and `504 Gateway Timeout`. These responses often indicate infrastructure, dependency, configuration, or unexpected application failures.
The distinction matters for retry behavior. A client should normally fix or change a `4xx` request rather than blindly retry it. Some `5xx` responses can be transient, so retries may be appropriate when the operation is safe to retry and the service's retry policy permits it; exponential backoff is commonly used.
Authentication and authorization errors are worth separating: `401` indicates that authentication credentials are missing or invalid, while `403` indicates that the server understood the identity or request context but refuses access. The exact semantics can depend on the API contract, so clients should follow documented behavior rather than infer everything from the status code alone.
Key points
- `4xx` usually means the request or its client-side context needs correction.
- `5xx` means the server failed while handling a request.
- Do not automatically retry every `4xx`; many are deterministic until the request changes.
- Some `5xx` failures are transient and can justify bounded retries with backoff.
- Use the API's documented semantics for authentication, authorization, validation, and retry behavior.
Interview questions
What is the difference between 400, 404, and 409?
`400 Bad Request` is commonly used when the request itself is invalid or cannot be processed because of malformed or invalid input. `404 Not Found` indicates that the requested resource could not be found, although APIs can define its use more specifically. `409 Conflict` indicates that the request conflicts with the current state of the target resource. Exact usage should follow the API's documented contract.
What is the difference between HTTP 4xx and 5xx status codes?
`4xx` responses generally indicate that the client request or its associated context is the reason the request cannot be fulfilled. `5xx` responses indicate that the server encountered a failure while processing the request. For example, invalid input can produce `400`, while an unexpected application failure can produce `500`. The distinction is useful because clients generally need to change a `4xx` request, whereas some `5xx` failures may be retried.
Should a Java client retry a 500 response?
It can, but a `500` response should not automatically be retried without considering the operation and API contract. The failure may be transient, but repeated retries can increase load during an outage. For retryable operations, use a bounded retry policy with exponential backoff and usually jitter. For non-idempotent operations, the client must also consider whether a retry could cause duplicate effects.
How would you distinguish 401 from 403 in a REST API?
A `401` response indicates that authentication is required or the supplied authentication credentials are not acceptable. A `403` response indicates that the server understood the request but refuses to authorize the requested action. A client receiving `401` may need to authenticate or refresh credentials. A `403` generally requires changing permissions, the requested operation, or the user's access context.