Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten.Erfahre mehr über dieses Experiment.
Prefer header
Der HTTP-Prefer-Header ermöglicht es Clients, Präferenzen für bestimmte Serververhaltensweisen während der Anfragenverarbeitung anzugeben.
Hinweis:Browser behandeln diePrefer- und diePreference-Applied-Header nicht: Sie werden in benutzerdefinierten, implementierungsspezifischen Clients verwendet.Stellen Sie sicher, dass sowohl der Client als auch der Server diesen Header unterstützen, bevor Sie sich im Produktionsbetrieb darauf verlassen.
Server sollten stillschweigend Präferenzen ignorieren, die sie nicht unterstützen, als ob der Header nicht vorhanden wäre.
| Header-Typ | Anforderungsheader |
|---|---|
| Verbotener Header-Name | Nein |
Syntax
Prefer: <preference>Direktiven
respond-asyncDer Client bevorzugt asynchrone Verarbeitung.Beispielsweise könnte der Server mit einer
202 Accepted-Antwort, die besagt, dass die Anfrage angenommen wurde, antworten, zusammen mit demLocation-Header, der eine URL enthält, die der Client verwenden kann, um den Status der Verarbeitung zu überwachen.return=minimalFordert, dass der Server minimalen Inhalt zurückgibt (eine nur aus Headern bestehende Antwort).
return=representationFordert eine vollständige Repräsentation der Ressource in der Antwort an.
wait=<seconds>Die Zeit, innerhalb der der Client erwartet, dass der Server eine Antwort liefert, ab dem Punkt, an dem die Anfrage empfangen wurde.Wenn die
respond-async-Präferenz ebenfalls angegeben ist, sollte der Server asynchron antworten, wenn die Verarbeitung der Anfrage die Wartezeit überschreiten wird.Andernfalls sollte der Server davon ausgehen, dass der Client nach derwait-Zeit ein Timeout erwartet (das Antwortverhalten hängt von der Implementierung des Servers ab).handling=lenientDer Client wünscht, dass der Server eine nachsichtige Validierung und Fehlerbehandlung bei der Verarbeitung der Anfrage anwendet.
handling=strictDer Client wünscht, dass der Server eine strikte Validierung und Fehlerbehandlung bei der Verarbeitung der Anfrage anwendet.
- Benutzerdefinierte Präferenz
Anbieter oder Anwendungen können ihre eigenen Präferenzen definieren, um spezifische Bedürfnisse zu erfüllen.Beispiel:
Prefer: timezone=America/Los_Angeles.
Beispiele
Minimalantwort anfordern
Die folgende Anfrage fordert eine minimale Antwort an.Dies ist typischerweise eine Antwort, die nur aus Headern besteht (im Gegensatz zureturn=representation, bei der eine Repräsentation im Antwortkörper enthalten ist):
POST /resource HTTP/1.1Host: example.comContent-Type: application/jsonPrefer: return=minimal{"id":123, "name": "abc"}Der Server antwortet mit einem201, enthält jedoch keinen Antwortkörper.DerLocation-Header enthält eine URL zum Standort der neu erstellten Ressource.Es ist nicht notwendig, einenPreference-Applied-Header einzuschließen, da das Fehlen eines Antwortkörpers einfach erkennbar ist:
HTTP/1.1 201 CreatedLocation: /resource?id=123Asynchrone Verarbeitung anfordern
Dieses Beispiel verlangt, dass der Server eine asynchrone Verarbeitung startet:
POST /process HTTP/1.1Host: example.comPrefer: respond-async{ "task": "check-broken-links"}Der Server antwortet mit einer202 Accepted-Antwort, die besagt, dass die Anfrage angenommen wurde und noch nicht asynchron abgeschlossen ist.EinLocation-Header verweist auf einen Statusmonitor, der den Status der Verarbeitung darstellt:
HTTP/1.1 202 AcceptedLocation: http://example.com/tasks/123/statusMehrere Präferenzen angeben
Die folgende Anfrage enthält zwei Präferenzen;timezone=Jupiter/Red_Spot, die eine Zeitzonenpräferenz für den Client angibt, undhandling=strict für strikte Validierung:
GET /events HTTP/1.1Host: example.comPrefer: handling=strict, timezone=Jupiter/Red_SpotIn dieser Implementierung führt eine ungültige Zeitzone zu einem Fehler:
HTTP/1.1 400 Bad RequestSpezifikationen
| Specification |
|---|
| Unknown specification # section-2 |
Siehe auch
Preference-Applied- Prefer-Header auf docs.oasis-open.org
- Prefer-Header auf docs.postgrest.org