it-swarm.com.de

RESTful API-Methoden; HEAD & OPTIONS

Ich schreibe ein RESTful API-Modul für eine Anwendung in PHP und bin ein bisschen gemischt mit den Verben HEAD und OPTIONS.

  • OPTIONS  Wird verwendet, um die verfügbaren HTTP-Verben für eine bestimmte Ressource abzurufen?
  • HEAD Wird verwendet, um festzustellen, ob eine bestimmte Ressource verfügbar ist?

Wenn jemand * diese Verben erklären könnte, wäre das sehr dankbar.

* Die Klarstellung bezog sich auf RESTful API-Architekturen, die HTTP-Verben neu definieren. Ich bin seitdem zu der Erkenntnis gekommen, dass sowohl HEAD als auch OPTIONSnicht neu definiert werden sollten und sich stattdessen vorhersehbar wie jede HTTP-Anwendung verhalten sollten. Oh, wie wir in 2 Jahren wachsen.

76
Dan Lugg

Stand: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 OPTIONEN

Die OPTIONS-Methode stellt eine Informationsanforderung zu den Kommunikationsoptionen dar, die in der durch den Request-URI angegebenen Anforderungs-/Antwortkette verfügbar sind. Mit dieser Methode kann der Client die mit einer Ressource oder den Funktionen eines Servers verbundenen Optionen und/oder Anforderungen bestimmen, ohne eine Ressourcenaktion zu implizieren oder einen Ressourcenabruf zu initiieren.

Antworten auf diese Methode können nicht zwischengespeichert werden.

Wenn die OPTIONS-Anforderung einen Entity-Body enthält (wie durch das Vorhandensein von Content-Length oder Transfer-Encoding angezeigt), MUSS der Medientyp durch ein Content-Type-Feld angegeben werden. Obwohl diese Spezifikation keine Verwendung für einen solchen Body definiert, können zukünftige Erweiterungen von HTTP den Body OPTIONS verwenden, um detailliertere Abfragen auf dem Server durchzuführen. Ein Server, der eine solche Erweiterung nicht unterstützt, KANN den Anforderungshauptteil verwerfen.

Wenn der Anforderungs-URI ein Sternchen ("*") ist, soll die OPTIONS-Anforderung im Allgemeinen auf den Server und nicht auf eine bestimmte Ressource angewendet werden. Da die Kommunikationsoptionen eines Servers normalerweise von der Ressource abhängen, ist die "*" - Anforderung nur als "Ping" - oder "No-Op" -Methode nützlich. Der Client kann lediglich die Funktionen des Servers testen. Dies kann zum Beispiel verwendet werden, um einen Proxy auf HTTP/1.1-Konformität (oder ein Fehlen davon) zu testen.

Wenn der Anforderungs-URI kein Stern ist, gilt die OPTIONS-Anforderung nur für die Optionen, die bei der Kommunikation mit dieser Ressource verfügbar sind.

Eine Antwort 200 MUSS Kopfzeilenfelder enthalten, die optionale Funktionen angeben, die vom Server implementiert wurden und auf diese Ressource anwendbar sind (z. B. Zulassen), möglicherweise einschließlich Erweiterungen, die nicht in dieser Spezifikation definiert sind. Der Antworttext, falls vorhanden, MUSS auch Informationen zu den Kommunikationsoptionen enthalten. Das Format für einen solchen Body wird in dieser Spezifikation nicht definiert, kann aber durch zukünftige Erweiterungen von HTTP definiert werden. Die Inhaltsverhandlung KANN verwendet werden, um das geeignete Antwortformat auszuwählen. Wenn kein Antworttext enthalten ist, MUSS die Antwort ein Feld für die Länge des Inhalts mit dem Feldwert "0" enthalten.

Das Max-Forwards-Anforderungsheader-Feld KANN verwendet werden, um einen bestimmten Proxy in der Anforderungskette anzuvisieren. Wenn ein Proxy eine OPTIONS-Anforderung in einem absoluten URL empfängt, für den die Weiterleitung von Anforderungen zulässig ist, MUSS der Proxy nach einem Max-Forwards-Feld suchen. Wenn der Max-Forwards-Feldwert Null ("0") ist, DARF der Proxy die Nachricht NICHT weiterleiten. Stattdessen SOLLTE der Proxy mit seinen eigenen Kommunikationsoptionen antworten. Wenn der Max-Forwards-Feldwert eine ganze Zahl größer als Null ist, MUSS der Proxy den Feldwert dekrementieren, wenn er die Anforderung weiterleitet. Wenn die Anforderung kein Feld für die maximale Weiterleitung enthält, darf die weitergeleitete Anforderung KEIN Feld für die maximale Weiterleitung enthalten.

9.4 HEAD

Die HEAD -Methode ist identisch mit GET, mit der Ausnahme, dass der Server in der Antwort KEINEN Nachrichtentext zurückgeben darf. Die in den HTTP-Headern als Antwort auf eine Anforderung HEAD enthaltenen Metainformationen MÜSSEN mit den Informationen identisch sein, die als Antwort auf eine GET-Anforderung gesendet wurden. Diese Methode kann verwendet werden, um Metainformationen über die von der Anforderung implizierte Entität zu erhalten, ohne den Entitätskörper selbst zu übertragen. Diese Methode wird häufig zum Testen von Hypertext-Links auf Gültigkeit, Zugänglichkeit und aktuelle Änderungen verwendet.

Die Antwort auf eine HEAD -Anforderung kann in dem Sinne zwischengespeichert werden, dass die in der Antwort enthaltenen Informationen möglicherweise zum Aktualisieren einer zuvor zwischengespeicherten Entität von dieser Ressource verwendet werden. Wenn die neuen Feldwerte anzeigen, dass sich die zwischengespeicherte Entität von der aktuellen Entität unterscheidet (was durch eine Änderung der Inhaltslänge, des Inhalts-MD5, des ETag oder der letzten Änderung angezeigt würde), MUSS der Cache den Cache-Eintrag als veraltet behandeln.

46
sdolgy

OPTIONS Methode gibt Informationen über [~ # ~] API [~ # ~] (Methoden/Inhaltstyp) zurück

HEAD Methode gibt Informationen über Ressource (Version/Länge/Typ) zurück

Serverantwort

[~ # ~] Optionen [~ # ~]

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

[~ # ~] Kopf [~ # ~]

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270
  • OPTIONS Identifizieren, welche HTTP-Methoden eine Ressource unterstützt, z. Können wir es LÖSCHEN oder über einen PUT aktualisieren?
  • HEAD Überprüft, ob sich eine Ressource geändert hat. Dies ist nützlich, wenn eine zwischengespeicherte Version einer Ressource verwaltet wird
  • HEAD Abrufen von Metadaten zur Ressource, z. Datenträgertyp oder -größe, bevor ein möglicherweise kostspieliger Abruf durchgeführt wird
  • HEAD, OPTIONS Testen, ob eine Ressource vorhanden und zugänglich ist. Beispiel: Überprüfen von vom Benutzer gesendeten Links in einer Anwendung

Hier ist ein netter und prägnanter Artikel darüber, wie HEAD und OPTIONS in die RESTful-Architektur passen.

48

OPTIONEN sagt Ihnen Dinge wie "Welche Methoden sind für diese Ressource erlaubt".

HEAD ruft den HTTP-Header ab, den Sie erhalten würden, wenn Sie eine GET-Anfrage stellen würden, jedoch ohne den Body. Auf diese Weise kann der Client bestimmen, welche Cacheinformationen, welcher Inhaltstyp und welcher Statuscode zurückgegeben werden. Die Verfügbarkeit ist nur ein kleiner Teil davon.

22
Quentin