Warum wird der HTTP-Standortheader nur für POST-Anfragen/201-Antworten (erstellt) festgelegt?

Question

Wenn ich 3xx-Antworten für einen Moment ignoriere, frage ich mich, warum der HTTP-Standortheader nur in Verbindung mit POST-Anfragen/201-Antworten (erstellt) verwendet wird.

Von dem RFC 2616-Spezifikation:

Bei 201 (erstellten) Antworten ist der Standort der der neuen Ressource, die durch die Anfrage erstellt wurde.

Dies ist ein weithin unterstütztes Verhalten, aber warum sollte es nicht mit anderen HTTP-Methoden verwendet werden?Nehmen Sie die JSON-API-Spezifikation als Beispiel:

Es definiert einen selbstreferenzierenden Link für die aktuelle Ressource innerhalb der JSON-Nutzlast (Dies ist bei RESTful-APIs nicht ungewöhnlich).Dieser Link ist in jeder Nutzlast enthalten.Die Spezifikation besagt, dass Sie MUSS Fügen Sie einen HTTP-Standortheader hinzu, wenn Sie ein neues Dokument per POST erstellen und der Wert mit dem selbstreferenzierenden Link in der Nutzlast übereinstimmt, dies ist jedoch der Fall NUR Wird für POST benötigt.Warum sich mit einem beschäftigen? Brauch Format für einen selbstreferenzierenden Link, wenn Sie einfach den HTTP-Standortheader verwenden könnten?

Notiz:Dies ist nicht spezifisch für die JSON-API.Das Gleiche gilt für HAL, JSON-Hyperschema oder andere Standards.

Anmerkung 2:Es ist nicht einmal spezifisch für den HTTP-Location-Header, da es dasselbe mit dem HTTP-Link-Header ist.Wie Sie sehen können, definieren die JSON-API, HAL und das JSON-Hyper-Schema nicht nur Konventionen für selbstreferenzierende Links, sondern auch, um Informationen über verwandte Ressourcen oder mögliche Aktionen für eine Ressource auszudrücken.Aber es scheint, dass sie alle einfach den HTTP-Link-Header verwenden könnten.(Sie könnten den selbstreferenzierenden Link sogar in den HTTP-Link-Header einfügen, wenn sie den HTTP-Standort-Header nicht verwenden möchten.)

Ich möchte nicht schimpfen, es scheint einfach eine Art „Neuerfindung des Rades“ zu sein.Es scheint auch sehr einschränkend zu sein:Wenn Sie nur den HTTP-Standort-/Link-Header verwenden würden, spielt es keine Rolle, ob Sie in Ihrem HTTP-Accept-Header nach JSON, XML oder was auch immer fragen, und Sie würden bei einer HEAD-Anfrage nützliche Metainformationen über Ihre Ressource erhalten, was nicht der Fall wäre enthalten die Links, wenn Sie JSON API, HAL oder JSON Hyper-Schema verwenden würden.

Answer 1

Die Semantik der Location Beim Header handelt es sich nicht um einen selbstreferenzierenden Link, sondern um einen Link, dem der Benutzeragent folgen sollte, um die Anfrage abzuschließen.Das ist bei Weiterleitungen sinnvoll, und wenn Sie eine neue Ressource erstellen, die sich an einem neuen Ort befindet, sollten Sie dorthin gehen.Wenn Ihre Anfrage bereits abgeschlossen ist, d. h. Sie bereits über eine vollständige Darstellung der gewünschten Ressource verfügen, ist es nicht sinnvoll, eine zurückzugeben Location.

Der Link Der Header kann als semantisches Äquivalent zu einem Hypertext-Link angesehen werden, sollte jedoch verwendet werden, um auf Metadaten zu verweisen, die sich auf die angegebene Ressource beziehen, wenn der Medientyp nicht Hypermedia-fähig ist, sodass er nicht die Funktionalität eines Links zu verwandten Ressourcen in ersetzt eine RESTful-API.

Die Notwendigkeit eines benutzerdefinierten Linkformats in der Ressourcendarstellung ist mit der Notwendigkeit verbunden, die Ressource von der zugrunde liegenden Implementierung und dem zugrunde liegenden Protokoll zu entkoppeln.REST ist nicht an HTTP gekoppelt und jedes Protokoll, für das es ein gültiges URI-Schema gibt, kann verwendet werden.Wenn Sie sich entschieden haben, das zu verwenden Link Header für alle Links, Sie koppeln an HTTP.

Nehmen wir an, Sie präsentieren einen FTP-Link, dem Kunden folgen können.Wo wäre das Link In diesem Fall?

Answer 2

Der Semantic des Standorts Header hängt vom Statuscode ab. Für 201 verknüpft es mit der neu erstellten Ressource, aber in 3xx-Anforderungen kann es mehrere (obwohl ähnliche) Bedeutungen haben. Ich denke, deshalb wird es allgemein für andere Verwendungen vermieden.

Die Alternative ist der Header des Inhaltsortes, der immer eine konsistente Bedeutung hat. Es sagt dem Client mit der kanonischen URL die Ressource, die es angefordert hat. Es ist rein informativ (im Gegensatz zum Ort, der erwartet wird, der vom Kunden verarbeitet wird).

So scheint der Content-Location-Header einem selbstverweisenden Link näher zu sein. Der Content-Location hat jedoch auch Nein definiert Verhalten für Put und Post . Es scheint auch ziemlich selten verwendet zu werden.

Diese Blogs Post Ort vs Content-Location ist ein schöner Vergleich. Hier ist ein Zitat:

Schließlich ist weder Header für die Verknüpfung der allgemeinen Zwecke gedacht.

In Summe, die eine standardisierte Eigenverbindung im Körper erfordern, scheint eine gute Idee zu sein. Es vermeidet viel Verwirrung auf der Clientseite.