HTTP Status 409 - Conflict

Der HTTP-Status-Code 409 Conflict signalisiert, dass der Request nicht ausgeführt werden kann, weil er mit dem aktuellen State der Resource in Konflikt steht. Typisch für Concurrent Updates, Duplicate Keys oder Version Conflicts. Client könnte Konflikt durch Änderung des Requests lösen.

Typ

Response-Status-Code

Syntax

Der Status Code wird zurückgegeben bei Resource State Conflicts.

http
HTTP/1.1 409 Conflict

Direktiven

Der 409 Conflict Status Code wird für State-Konflikte verwendet.

State Conflict
Request kann nicht verarbeitet werden wegen Konflikt mit aktuellem Resource State. Unterscheidet sich von 400 (invalid Input) – Request ist technisch valid, aber semantisch konfliktär.
Concurrent Modification
Häufigster Usecase: Zwei Clients versuchen gleichzeitig Resource zu modifizieren. Optimistic Locking mit ETags verhindert Lost Updates via 409.
Duplicate Resource
Auch für Unique-Constraint-Violations (duplicate Username, Email, Primary Key). Client muss alternative Resource-Identifier wählen.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für Status 409.

Beispiel 1 Optimistic Locking ETag Conflict

http
PUT /api/documents/doc-123 HTTP/1.1
Host: api.example.com
If-Match: "v1-abc"
Content-Type: application/json

{"content": "Updated text"}

HTTP/1.1 409 Conflict
ETag: "v2-def"
Content-Type: application/json

{
  "error": "version_conflict",
  "message": "Document was modified by another user",
  "expected_version": "v1-abc",
  "current_version": "v2-def",
  "action": "Fetch latest version and retry"
}

Beispiel 2 Duplicate Username Creation

http
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"username": "alice", "email": "alice@example.com"}

HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "duplicate_resource",
  "message": "Username 'alice' already exists",
  "conflicting_field": "username",
  "suggestion": "Choose a different username"
}

Beispiel 3 State Transition Conflict

http
POST /api/orders/789/cancel HTTP/1.1
Host: api.example.com

HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "invalid_state_transition",
  "message": "Cannot cancel order in 'shipped' state",
  "current_state": "shipped",
  "allowed_transitions": ["return", "complete"]
}

Concurrent Modification Conflict Flow

409 Conflict bei Concurrent Update mit Optimistic Locking

Vorteile für die Systemarchitektur

  • Optimistic Locking: Verhindert Lost Updates bei Concurrent Modifications. Client kann Conflicts erkennen und User-Resolution triggern statt silent Data Loss.
  • Clear Conflict Semantics: 409 unterscheidet sich von 400 (invalid Request) und 422 (semantic Validation). Signalisiert explizit State-Conflicts, die durch Retry mit updated State lösbar sind.
  • Data Integrity: Ermöglicht Unique-Constraint-Enforcement auf API-Level. Verhindert Duplicate Resources durch klare Client-Notification mit Konflikt-Details.

Spezifikation

RFC 9110, Section 15.5.10 – HTTP Semantics https://www.rfc-editor.org/rfc/rfc9110.html#name-409-conflict

Weitere Spezifikationen

If-Match Header, PUT Method