HTTP Preference-Applied Header

Der HTTP-Header Preference-Applied ist ein Response-Header, der dem Client mitteilt, welche Präferenzen aus dem Prefer Request-Header vom Server tatsächlich respektiert wurden. Dies schafft Transparenz über die Verarbeitung optionaler Client-Wünsche.

Typ

Response-Header

Syntax

Der Header listet die angewendeten Präferenzen aus dem ursprünglichen Request auf.

http
Preference-Applied: respond-async
Preference-Applied: return=minimal

Direktiven

Die Direktiven spiegeln die respektierten Präferenzen aus dem Prefer Request-Header wider.

respond-async
Bestätigt, dass Server die Operation asynchron verarbeitet und 202 Accepted zurückgibt.
return=minimal
Bestätigt, dass Server nur minimalen Response ohne Body liefert.
return=representation
Bestätigt, dass Server vollständige Ressourcen-Repräsentation in Response inkludiert.
wait=<seconds>
Bestätigt die tatsächlich verwendete Wartezeit für synchrone Verarbeitung.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für den Preference-Applied-Header.

Beispiel 1 Asynchrone Verarbeitung bestätigt

http
POST /api/exports HTTP/1.1
Host: api.example.com
Prefer: respond-async
Content-Type: application/json

{"format": "csv", "date_range": "2024-01"}

Server respektiert async-Präferenz und bestätigt dies explizit.

http
HTTP/1.1 202 Accepted
Location: /api/tasks/export-xyz-789
Preference-Applied: respond-async
Content-Length: 0

Beispiel 2 Minimaler Response bei POST

http
POST /api/products HTTP/1.1
Host: api.example.com
Prefer: return=minimal
Content-Type: application/json

{"name": "Laptop Pro", "price": 1299.99}

Server erstellt Produkt und gibt nur Location ohne Body zurück.

http
HTTP/1.1 201 Created
Location: /api/products/prod-456
Preference-Applied: return=minimal

Beispiel 3 Server ignoriert Präferenz

http
PATCH /api/users/123 HTTP/1.1
Host: api.example.com
Prefer: return=minimal
Content-Type: application/json

{"email": "newemail@example.com"}

Server kann Präferenz nicht respektieren und sendet keinen Preference-Applied Header.

http
HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "email": "newemail@example.com", "updated_at": "2024-03-15T16:45:00Z"}

Preference Confirmation Flow

Preference-Applied Bestätigungsfluss

Vorteile für die Systemarchitektur

Explizite Präferenz-Bestätigung verbessert API-Verlässlichkeit und Client-Logik.

  • Transparente Verarbeitung: Clients wissen exakt, welche Präferenzen respektiert wurden
  • Fehlertoleranz: Clients können auf fehlende Bestätigung reagieren und Fallback-Logik anwenden
  • API-Debugging: Explizite Bestätigung vereinfacht Fehlersuche bei Präferenz-basierten Operationen

Spezifikation

RFC 7240, Section 3 – Prefer Header for HTTP https://www.rfc-editor.org/rfc/rfc7240.html#section-3

Weitere Spezifikationen

Prefer Header