HTTP Status 428 - Precondition Required

Der HTTP-Status-Code 428 Precondition Required signalisiert, dass Server Conditional-Request-Headers verlangt bevor Request verarbeitet wird. Client muss If-Match, If-Unmodified-Since oder ähnliche Headers senden. Verhindert Lost-Update-Problem bei Concurrent-Modifications. Server enforced Optimistic-Locking.

Typ

Response-Status-Code

Syntax

Der Status Code wird zurückgegeben wenn Conditional-Headers fehlen.

http
HTTP/1.1 428 Precondition Required

Direktiven

Der 428 Precondition Required Status Code wird für Conditional-Request-Enforcement verwendet.

Lost Update Prevention
Server verlangt Conditional-Headers um Lost-Update-Problem zu vermeiden. Wenn zwei Clients gleichzeitig Resource modifizieren, müssen sie Current-State mit If-Match/ETag verifizieren.
Optimistic Locking Enforcement
428 enforced Optimistic-Locking-Pattern. Client muss zuerst GET-Request machen um ETag zu erhalten, dann PUT/PATCH mit If-Match-Header senden. Stellt sicher dass Client auf aktuellem State basiert.
Conditional Request Headers
Server acceptiert nur Requests mit If-Match, If-Unmodified-Since, If-None-Match oder If-Modified-Since Headers. Ohne diese Headers wird Request mit 428 rejected.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für Status 428.

Beispiel 1 Update Without If-Match Header

http
PUT /api/documents/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title": "Updated Document", "content": "New content"}

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{
  "error": "precondition_required",
  "message": "This endpoint requires If-Match header for updates",
  "details": "Perform GET request first to obtain current ETag",
  "example": "If-Match: \"abc123def456\"",
  "docs": "https://api.example.com/docs/optimistic-locking"
}

Beispiel 2 Delete Without Conditional Header

http
DELETE /api/users/alice HTTP/1.1
Host: api.example.com
Authorization: Bearer token123

HTTP/1.1 428 Precondition Required
Content-Type: application/json
ETag: "user-v42"

{
  "error": "conditional_request_required",
  "message": "User deletion requires If-Match header",
  "current_etag": "user-v42",
  "reason": "Prevents accidental deletion of modified resource",
  "retry": "Include 'If-Match: \"user-v42\"' header"
}

Beispiel 3 Concurrent Modification Protection

http
PATCH /api/settings HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"theme": "dark", "notifications": true}

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{
  "status": 428,
  "error": "precondition_required",
  "message": "Settings updates require If-Unmodified-Since or If-Match header",
  "details": "This prevents overwriting changes made by other sessions",
  "last_modified": "2025-10-01T14:30:00Z",
  "current_etag": "settings-abc-123"
}

Optimistic Locking Enforcement Flow

428 Precondition Required enforced Optimistic-Locking für Concurrent-Update-Protection

Vorteile für die Systemarchitektur

  • Data Consistency Protection: 428 verhindert Lost-Update-Problem bei Concurrent-Modifications. Server enforced dass Clients Current-State verifizieren bevor Updates durchgeführt werden.
  • Conflict Detection Enforcement: Durch Mandatory-Conditional-Requests können Conflicts früh detected werden. Client erfährt via 412-Precondition-Failed wenn Resource zwischenzeitlich geändert wurde.
  • API Safety Improvement: 428 macht APIs safer indem Accidental-Overwrites verhindert werden. Developers müssen explizit Optimistic-Locking implementieren, nicht optional sondern enforced.

Spezifikation

RFC 6585, Section 3 – Additional HTTP Status Codes https://www.rfc-editor.org/rfc/rfc6585.html#section-3

Weitere Spezifikationen

If-Match Header, HTTP Status 412 - Precondition Failed