Choose the most specific useful code
Status codes should let clients decide what to do next. Pair them with a stable error body and relevant headers rather than returning 200 OK for every outcome.
Avoid leaking sensitive details
Client-facing errors should be actionable without exposing stack traces, SQL messages, internal hostnames, credentials, or authorization rules attackers can probe.
Read the complete exchange
Inspect the method, URL, request and response headers, redirect chain, body, proxy logs and upstream timing. The status code alone is rarely the full diagnosis.
Frequently confused HTTP responses
| Codes | Practical distinction |
|---|---|
401 vs 403 | 401 means valid authentication is required; 403 means the request is understood but not permitted. |
404 vs 410 | 404 does not say whether absence is temporary; 410 explicitly indicates the resource is intentionally gone. |
400 vs 422 | 400 covers a malformed or unusable request; 422 is useful when syntax is understood but instructions fail semantic validation. |
301/302 vs 307/308 | 307 and 308 explicitly preserve the request method; 301 and 302 have historical method-rewrite behavior in clients. |
502 vs 504 | 502 means an invalid upstream response; 504 means the upstream response did not arrive in time. |
HTTP status FAQ
Are all 4xx responses the client’s fault?
The 4xx class indicates the request cannot be fulfilled as sent, but a server configuration, stale link, authorization policy or API design issue may still be the root cause.
Should an API include error details?
Yes—return a documented machine-readable error shape with a stable code and safe message. Never expose private implementation details.
When is usage counted?
One usage is recorded when you press Look up status or press Enter. Live filtering, categories, details, and copying do not add uses.