HTTP Status Classes – 2xx Success Codes & 4xx Client Errors

This post is a conceptual explanation of HTTP status classes – including exam questions and tags.

In a Nutshell

• 2xx: successful processing (200 OK, 201 Created, 202 Accepted, 204 No Content)
• 4xx: client-caused errors (400, 401, 403, 404, 409, 422, 429)

Compact Technical Description

2xx signals successful processing of a request, 4xx indicates client-caused errors. 2xx includes typical successes: 200 OK for read operations, 201 Created with Location header for newly created resources, 202 Accepted for asynchronously initiated operations, 204 No Content when no body is returned. 4xx describes client errors: 400 Bad Request for validation errors, 401 Unauthorized for missing authentication, 403 Forbidden for missing authorization, 404 Not Found for unknown resources, 409 Conflict for version conflicts, 422 Unprocessable Content for semantically invalid data, 429 Too Many Requests for rate limits.

Exam-Relevant Key Points

• 201 Created always with Location header pointing to the new resource
• 204 No Content only use when no body is actually needed
• 202 Accepted for asynchronous workflows with downstream status endpoint
• Consistent error structure with Problem Details and traceable error ID
• 409 Conflict for ETag collision cases and concurrent updates
• 401 for missing authentication, 403 for missing authorization
• Clean codes reduce support effort and integration costs
• Describe status codes and error objects per operation in OpenAPI

Core Components

1. Status line with code and reason phrase
2. 2xx codes: 200, 201, 202, 204
3. 4xx codes: 400, 401, 403, 404, 409, 422, 429
4. Headers: Location, Retry After, ETag, Content-Type
5. Conditional requests: If-Match, If-None-Match, If-Modified-Since
6. Idempotency rules per method
7. Error objects: Problem Details (type, title, status, detail, instance)
8. Pagination in 200 responses with links (First, Prev, Next, Last)
9. Observability: Correlation ID, Trace ID, Logging
10. Test procedures: Negative tests, Contract tests, Retry and ETag conflicts

Practical Example

// Creating an order with later confirmation
POST https://api.shop.de/orders
Headers: Content-Type: application/json, Idempotency-Key: abc-123
Body: { customerId: 123, items: [{ sku: "A1", qty: 2 }] }

Response for immediate creation:
Status: 201 Created
Headers: Location: https://api.shop.de/orders/42, ETag: W/"7c9"
Body: { id: 42, status: "created" }

Response for asynchronous processing:
Status: 202 Accepted
Headers: Location: https://api.shop.de/jobs/987, Retry-After: 10
Body: { jobId: 987, state: "queued" }

Conflict due to outdated ETag:
PUT https://api.shop.de/orders/42
Headers: If-Match: W/"7c9"
Body: { status: "confirmed" }

Server has newer version:
Status: 412 Precondition Failed
Body: application/problem+json
{ type: "https://problems/concurrency", title: "Precondition failed", status: 412, detail: "Version mismatch", instance: "/orders/42" }

Advantages and Disadvantages

Advantages

• Clear semantics, better client control
• Simpler error handling
• Better caching strategies and repeatability
• Reduced support effort

Disadvantages

• Incorrect codes confuse clients
• Complicate caching and retries
• Different framework defaults lead to inconsistencies
• Additional care needed in documentation and tests

Typical Exam Questions (with Short Answers)

1. When 201 Created and which headers are relevant? For resource creation, Location points to new URI, optional ETag for updates.
2. Difference between 200 OK vs. 204 No Content? 200 transfers representation, 204 omits body, use 204 only when client doesn’t need content.
3. Asynchronous workflows with status codes? 202 Accepted with status endpoint in Location header, optional Retry-After.
4. 401 vs. 403, when which? 401 for missing/invalid authentication, 403 for authenticated user without rights.
5. 409 Conflict in REST APIs? Application conflicts: version conflicts, duplicate resources, business rule violations.
6. 422 instead of 400 Bad Request? 422 for syntactically correct but semantically invalid JSON (domain rule violations).
7. ETag and If-Match for safe updates? Client sends If-Match, server executes update only on tag match, otherwise 412.
8. Idempotency with status codes and retries? Idempotent methods (PUT, DELETE) enable retries, POST requires Idempotency-Key.

Most Important Sources

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