Was ist der Nutzen von PUT- und DELETE-HTTP-Anforderungsmethoden?

Ich habe viel darüber gelesen, kann aber keine Schlussfolgerung zu diesem Thema ziehen.

Ich habe jedoch noch nie PUT- oder DELETE-HTTP-Anforderungsmethoden verwendet. Meine Tendenz ist, GET zu verwenden, wenn der Status des Systems (meine Anwendung oder Website) möglicherweise nicht betroffen ist (wie die Produktliste), und POST zu verwenden, wenn es betroffen ist (Bestellung aufgegeben). Ist es nicht ausreichend oder fehlt mir etwas?

DELETE dient zum Löschen der Anforderungsressource:

Die DELETE-Methode fordert den Ursprungsserver auf, die durch den Request-URI identifizierte Ressource zu löschen. Diese Methode kann durch menschliches Eingreifen (oder auf andere Weise) auf dem Ursprungsserver überschrieben werden. Dem Client kann nicht garantiert werden, dass der Vorgang ausgeführt wurde, auch wenn der vom Ursprungsserver zurückgegebene Statuscode anzeigt, dass die Aktion erfolgreich abgeschlossen wurde.

PUT dient zum Speichern oder Aktualisieren einer Ressource auf dem Server:

Die PUT-Methode fordert an, dass die eingeschlossene Entität unter dem angegebenen Anforderungs-URI gespeichert wird. Wenn sich der Anforderungs-URI auf eine bereits vorhandene Ressource bezieht, MUSS die eingeschlossene Entität als modifizierte Version der auf dem Ursprungsserver befindlichen Entität betrachtet werden. Wenn der Anforderungs-URI nicht auf eine vorhandene Ressource verweist und dieser URI vom anfordernden Benutzeragenten als neue Ressource definiert werden kann, kann der Ursprungsserver die Ressource mit diesem URI erstellen.

Für die vollständige Spezifikation besuchen Sie:

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

Da aktuelle Browser leider keine anderen Verben als POST und GET in HTML-Formularen unterstützen , können Sie HTTP normalerweise nicht in vollem Umfang nutzen (Sie können ihre Übermittlung jedoch weiterhin über JavaScript entführen). Das Fehlen einer Unterstützung für diese Methoden in HTML-Formularen führte zu URIs, die Verben enthielten, wie zum Beispiel

POST http://example.com/order/1/delete

oder noch schlimmer

POST http://example.com/deleteOrder/id/1

CRUD-Semantik effektiv über HTTP tunneln. Aber Verben sollten niemals Teil der URI sein. Stattdessen bietet HTTP bereits den Mechanismus und die Semantik zum CRUD einer Ressource (z. B. einer Bestellung) über die HTTP-Methoden. HTTP ist ein Protokoll und nicht nur ein Datentunneldienst.

Um eine Ressource auf dem Webserver zu löschen, rufen Sie an

DELETE http://example.com/order/1

und um es zu aktualisieren, würden Sie anrufen

PUT http://example.com/order/1

und stellen Sie die aktualisierte Ressourcendarstellung im PUT-Text bereit, damit der Webserver sie dann anwenden kann.

Wenn Sie also eine Art Client für eine REST-API erstellen , wird diese wahrscheinlich PUT- und DELETE-Anforderungen senden. Dies kann ein Client sein, der in einem Browser erstellt wurde, z. B. das Senden von Anforderungen über JavaScript, oder ein Tool, das auf einem Server ausgeführt wird usw.

Weitere Informationen finden Sie unter:

• http://martinfowler.com/articles/richardsonMaturityModel.html
• Sind die Methoden PUT, DELETE, HEAD usw. in den meisten Webbrowsern verfügbar?
• Warum gibt es in HTML-Formularen keine PUT- und DELETE-Methoden?
• Sollten PUT und DELETE in Formularen verwendet werden?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

Mit dem HTTP-Anforderungsverb wie GET, POST, DELETE, PUT usw. können Sie RESTful-Webanwendungen erstellen. Lesen Sie hier darüber: http://en.wikipedia.org/wiki/Representational_state_transfer

Der einfachste Weg, um die Vorteile daraus zu erkennen, ist dieses Beispiel. Jedes MVC-Framework verfügt über eine Router/DispatcherURL, die actionControllern URLs zuordnet. Also URL wie folgt : /blog/article/1würde aufrufen blogController::articleAction($id);Jetzt kennt dieser Router nur noch die URL oder/blog/article/1/

Wenn dieser Router jedoch das gesamte HTTP-Anforderungsobjekt anstelle nur der URL kennt, kann er auf das HTTP-Anforderungsverb (GET, POST, PUT, DELETE ...) und viele andere nützliche Informationen zur aktuellen HTTP-Anforderung zugreifen.

Auf diese Weise können Sie die Anwendung so konfigurieren, dass sie dieselbe URL akzeptiert und sie je nach HTTP-Anforderungsverb verschiedenen actionControllern zuordnet.

Beispielsweise:

Wenn Sie Artikel 1 abrufen möchten, können Sie dies tun:

GET /blog/article/1 HTTP/1.1

Wenn Sie jedoch Artikel 1 löschen möchten, gehen Sie folgendermaßen vor:

DELETE /blog/article/1 HTTP/1.1

Beachten Sie, dass beide HTTP-Anforderungen denselben URI / blog / article / 1 haben. Der einzige Unterschied besteht im Verb HTTP-Anforderung. Und basierend auf diesem Verb kann Ihr Router verschiedene actionController aufrufen. Auf diese Weise können Sie saubere URLs erstellen.

Lesen Sie diese beiden Artikel, sie könnten Ihnen helfen:

Symfony 2 - HTTP-Grundlagen

Symfony 2 - Routing

In diesen Artikeln geht es um das Symfony 2-Framework. Sie können Ihnen jedoch dabei helfen, herauszufinden, wie HTTP-Anforderungen und -Antworten funktionieren.

Hoffe das hilft!

Sichere Methoden: Ressource
abrufen / Keine Änderung der Ressource Idempotent: Keine Änderung des Ressourcenstatus bei
mehrmaliger Anforderung Unsichere Methoden: Erstellen oder Aktualisieren der Ressource / Änderung der Ressource
Nicht-Idempotent: Änderung des Ressourcenstatus bei mehrmaliger Anforderung

Entsprechend Ihrer Anforderung:

1) Verwenden Sie für einen sicheren und idempotenten Betrieb (Fetch Resource) --------- GET METHOD
2) Für einen unsicheren und nicht idempotenten Betrieb (Insert Resource) verwenden Sie --------- POST METHOD
3) Für unsichere und idempotente Operationen (Ressource aktualisieren) verwenden Sie --------- PUT-METHODE
3) Für unsichere und idempotente Operationen (Ressource löschen) verwenden Sie --------- LÖSCHMETHODE

Obwohl ich das Risiko eingehen möchte, nicht beliebt zu sein, sage ich, dass sie heutzutage nicht mehr nützlich sind .

Ich denke, sie waren in der Vergangenheit gut gemeint und nützlich, als beispielsweise DELETE den Server aufforderte, die unter der angegebenen URL gefundene Ressource zu löschen, und PUT (mit seinem Geschwister-PATCH) den Server aufforderte, auf idempotente Weise zu aktualisieren.

Die Dinge entwickelten sich und URLs wurden virtuell (siehe z. B. das Umschreiben von URLs ), wodurch Ressourcen ihre ursprüngliche Bedeutung als realer Ordner / Unterbedarf / Datei verloren. Daher verloren CRUD-Aktionsverben, die von HTTP-Protokollmethoden (GET, POST, PUT / PATCH, DELETE) abgedeckt wurden, den Überblick .

Nehmen wir ein Beispiel:

• / api / entity / list / {id} vs GET / api / entity / {id}
• / api / entity / add / {id} vs POST / api / entity
• / api / entity / edit / {id} gegen PUT / api / entity / {id}
• / api / entity / delete / {id} vs DELETE / api / entity / {id}

Auf der linken Seite ist die HTTP-Methode nicht geschrieben, im Wesentlichen spielt es keine Rolle (POST und GET sind ausreichend) und auf der rechten Seite werden geeignete HTTP-Methoden verwendet.

Die rechte Seite sieht elegant, sauber und professionell aus. Stellen Sie sich vor, Sie müssen jetzt einen Code pflegen, der die elegante API verwendet, und Sie müssen suchen, wo der Löschaufruf ausgeführt wird. Sie suchen nach "api / entity" und müssen unter den Ergebnissen sehen, welche DELETE ausführt. Oder noch schlimmer, Sie haben einen Junior-Programmierer, der versehentlich PUT mit DELETE umgeschaltet hat und als URL die gleiche Scheiße passiert ist.

Meiner Meinung nach hat das Einfügen des Aktionsverbs in die URL Vorteile gegenüber der Verwendung der entsprechenden HTTP-Methode für diese Aktion, auch wenn sie nicht so elegant ist. Wenn Sie sehen möchten, wo der Löschaufruf erfolgt, müssen Sie nur nach "api / entity / delete" suchen. suchen und Sie werden ihn sofort finden.

Das Erstellen einer API ohne das gesamte HTTP-Methodenarray erleichtert das anschließende Konsumieren und Verwalten