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

This article is a concept guide to HTTP status classes—including exam questions and key takeaways.

In a Nutshell

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

Core Technical Overview

2xx indicates successful request processing, while 4xx marks client-caused errors. The 2xx family covers typical success scenarios: 200 OK for read operations, 201 Created with a Location header for newly created resources, 202 Accepted for asynchronously initiated operations, and 204 No Content when no response body is needed. The 4xx family describes client errors: 400 Bad Request for validation failures, 401 Unauthorized for missing authentication, 403 Forbidden for insufficient permissions, 404 Not Found for unknown resources, 409 Conflict for version mismatches, 422 Unprocessable Content for semantically invalid data, and 429 Too Many Requests for rate limit violations.

Exam-Relevant Highlights

• Always include a Location header with 201 Created, pointing to the new resource
• Use 204 No Content only when genuinely no response body is needed
• 202 Accepted suits asynchronous workflows with a downstream status endpoint
• Maintain consistent error structures using Problem Details with traceable error IDs
• 409 Conflict applies to ETag collisions and concurrent updates
• 401 signals missing authentication; 403 signals missing authorization
• Clean status codes reduce support overhead and integration costs
• Document all 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. Testing: negative tests, contract tests, retry and ETag conflict scenarios

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 stale ETag:
PUT https://api.shop.de/orders/42
Headers: If-Match: W/"7c9"
Body: { status: "confirmed" }

Server has a 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 and better client control
• Simpler error handling
• Better caching strategies and request retryability
• Reduced support burden

Disadvantages

• Wrong codes confuse clients
• Complicate caching and retries
• Inconsistent framework defaults lead to inconsistencies
• Requires extra care in documentation and testing

Common Exam Questions (with Brief Answers)

1. When to use 201 Created and which headers matter? Use it for new resource creation. The Location header points to the new URI; ETag is optional for future updates.

2. Difference between 200 OK and 204 No Content? 200 OK includes a representation; 204 No Content omits the body. Use 204 only when the client needs no content.

3. Status codes for asynchronous workflows? Use 202 Accepted with a status endpoint in the Location header; optionally include Retry-After.

4. When to use 401 versus 403? 401 Unauthorized applies to missing or invalid authentication; 403 Forbidden applies to authenticated users lacking permissions.

5. When does 409 Conflict appear in REST APIs? For application-level conflicts: version mismatches, duplicate resources, or business rule violations.

6. Why use 422 instead of 400 Bad Request? 422 Unprocessable Content marks syntactically valid but semantically invalid JSON (domain rule violations).

7. How do ETag and If-Match ensure safe updates? The client sends If-Match with an ETag. The server executes the update only if the tag matches; otherwise it returns 412 Precondition Failed.

8. Idempotency, status codes, and retries—how do they connect? Idempotent methods (PUT, DELETE) permit safe retries. POST requires an Idempotency-Key header for the same guarantee.

Next in the API Learning Path

The next article in the API learning path covers HTTP/2 and HTTP/3: Protocol Overview—the evolution of the HTTP protocol with multiplexing, QUIC, and improved performance.

Key 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