wake-up-neo.com

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

Ich habe viel darüber gelesen, bin aber nicht in der Lage, eine Schlussfolgerung zu diesem Thema zu ziehen.

Aber ich habe noch nie PUT- oder DELETE-HTTP-Request-Methoden verwendet. Ich tendiere dazu, GET zu verwenden, wenn der Status des Systems (meiner Anwendung oder Website) möglicherweise nicht betroffen ist (wie die Produktliste), und POST wenn er betroffen ist (Bestellung aufgegeben). Reicht es aus oder fehlt mir etwas?

82
Rupesh Patel

DELETE dient zum Löschen der Anforderungsressource:

Die DELETE-Methode fordert den Origin-Server auf, die durch den Request-URI angegebene Ressource zu löschen. Diese Methode kann durch menschliches Eingreifen (oder auf andere Weise) auf dem Origin-Server außer Kraft gesetzt werden. Dem Client kann nicht garantiert werden, dass die Operation ausgeführt wurde, selbst wenn der vom Origin-Server zurückgegebene Statuscode angibt, dass die Aktion erfolgreich abgeschlossen wurde.

Mit PUT wird eine Ressource auf dem Server abgelegt oder aktualisiert:

Die PUT-Methode fordert an, dass die eingeschlossene Entität unter dem angegebenen Request-URI gespeichert wird. Wenn sich der Anforderungs-URI auf eine bereits vorhandene Ressource bezieht, MUSS die beigefügte Entität als eine modifizierte Version der auf dem Origin-Server 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 Origin-Server die Ressource mit diesem URI erstellen.

Für die vollständige Spezifikation besuchen Sie:

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 mit ihnen nutzen (Sie können immer noch Hijack ausführen) Die fehlende Unterstützung dieser Methoden in HTML-Formularen führte zu URIs, die Verben enthalten, wie zum Beispiel

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

oder noch schlimmer

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

effizientes Tunneln der CRUD-Semantik über HTTP. Aber Verben sollten niemals Teil der URI sein. Stattdessen stellt HTTP bereits den Mechanismus und die Semantik bereit, um eine Ressource (z. B. eine Reihenfolge) über die HTTP-Methoden zu CRUDen. HTTP ist ein Protokoll und nicht nur ein Datentunnelungsdienst.

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 geben Sie die aktualisierte Ressourcendarstellung im PUT-Body an, damit der Webserver sie dann anwenden kann.

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

Für weitere Informationen besuchen Sie:

82
Gordon

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

Der einfachste Weg, um die Vorteile zu sehen, besteht darin, sich dieses Beispiel anzusehen. Jedes MVC-Framework verfügt über einen Router/Dispatcher, Der URLs zu actionControllern zuordnet. Eine URL wie diese: /blog/article/1 Würde blogController::articleAction($id); aufrufen. Jetzt kennt dieser Router nur die URL oder /blog/article/1/

Wenn diesem Router jedoch das gesamte HTTP-Anforderungsobjekt und nicht nur die URL bekannt ist, 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 abhängig vom 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 wie folgt vor:

DELETE /blog/article/1 HTTP/1.1

Beachten Sie, dass beide HTTP-Anforderungen den gleichen URI haben (/ blog/article/1). Der einzige Unterschied ist das HTTP-Anforderungsverb. Und basierend auf diesem Verb kann Ihr Router verschiedene actionController aufrufen. Auf diese Weise können Sie ordentliche 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!

23
Limeni

Sichere Methoden: Ressource abrufen/Keine Änderung der Ressource
Idempotent: Keine Änderung des Ressourcenstatus, wenn mehrmals angefordert
nsichere Methoden: Ressource erstellen oder aktualisieren/Änderung in Ressource
Nicht idempotent: Änderung des Ressourcenstatus, wenn mehrmals angefordert

entsprechend Ihrer Anforderung:

1) Für einen sicheren und idempotenten Betrieb (Fetch Resource) verwenden Sie --------- GET METHOD
2) Verwenden Sie für unsichere und nicht-idempotente Operationen (Ressource einfügen) --------- POST-METHODE
3) Verwenden Sie --------- PUT METHOD für unsicheren und nicht sicheren Betrieb (Update Resource)
3) Verwenden Sie --------- DELETE METHOD für unsichere und nicht sichere Vorgänge (Delete Resource)

1
user1953168