HTTP Status Codes 2xx and 4xx Explained

This post explains the most important 2xx and 4xx status codes—including exam questions and key takeaways.

In a Nutshell

2xx indicates successful processing. 4xx marks client errors. Using the correct codes improves API clarity, caching behavior, idempotency, and overall robustness.

Quick Technical Reference

Common 2xx:

• 200 OK (read/successful)
• 201 Created + Location (resource created)
• 202 Accepted (async started)
• 204 No Content (no body)

Common 4xx:

• 400 Bad Request (syntax/validation)
• 401 Unauthorized (missing auth)
• 403 Forbidden (no permission)
• 404 Not Found
• 409 Conflict
• 422 Unprocessable Content (semantically invalid)
• 429 Too Many Requests (rate limit) + Retry-After

Standard error objects following RFC 7807 (Problem Details) streamline debugging and documentation.

Exam-Relevant Checkpoints

• Always include Location with 201
• Use 204 only when there’s genuinely no body
• 202 with status endpoint (Location) for async workflows
• Distinguish 401 from 403 carefully
• Use 409/412 for concurrency/ETag conflicts
• Never leak sensitive details in error responses
• Document status codes per endpoint in OpenAPI

Core Components

1. 2xx: 200/201/202/204
2. 4xx: 400/401/403/404/409/422/429
3. Headers: Location, Retry-After, ETag, Content-Type
4. Conditional requests (If-Match)
5. Problem Details (type/title/status/detail/instance)
6. Tests (negative tests/contract tests)

Practical Example

POST /orders
→ 201 Created
Location: /orders/42
ETag: W/"7c9"

PUT /orders/42 (If-Match: W/"7c9")
→ 412 Precondition Failed on version conflict

GET /orders/9999
→ 404 Not Found

Strengths and Weaknesses

Strengths

• Clear semantics
• Fewer integration bugs
• Better caching and retry behavior

Weaknesses

• Wrong codes cause confusion
• Framework defaults lead to inconsistencies
• Requires more care and testing

Common Exam Questions (with Brief Answers)

1. When do you use 201 and which header? When creating a resource; Location points to the new URI.
2. 200 vs 204? 200 includes a body, 204 does not.
3. 401 vs 403? 401 means auth is missing or invalid; 403 means lacking permissions.
4. When use 422 instead of 400? When JSON is syntactically valid but semantically invalid.

Open-Ended Answer

Define per endpoint: which codes are allowed, when they occur, which headers are set, and what error objects look like. This significantly reduces support overhead.

Learning Strategy

1. Analyze status codes from a public API.
2. Sketch a sequence diagram for a 202 workflow.
3. Practice flashcards (code → meaning → headers).
4. Avoid using 200 as a catch-all.

Key Resources

1. https://www.rfc-editor.org/rfc/rfc9110
2. https://developer.mozilla.org/docs/Web/HTTP/Status
3. https://www.rfc-editor.org/rfc/rfc7807