Warum brauchen wir etwas mehr als HTTP GET, PUT, POST?
https://stackoverflow.com/questions/147187
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Was ist der praktische Nutzen der Verwendung von HTTP GET, PUT, DELETE, POST, HEAD? Warum nicht konzentrieren sich auf ihre Verhaltensleistungen (Sicherheit und Idempotenz), ihre Namen zu vergessen, und verwenden Sie GET, PUT oder POST je nachdem, welches Verhalten wir wollen?
Warum sollten wir PUT und POST nicht nur verwenden, GET, (& Drop HEAD, DELETE)?
Lösung
Der [REST] [1] Ansatz verwendet POST, GET, PUT und DELETE die CRUD Regeln für eine Web-Ressource zu implementieren. Es ist eine einfache und saubere Art und Weise Objekte auf Anfragen über das Internet verfügbar zu machen. Es ist Web-Services ohne die Gemeinkosten.
Nur die semantischen Unterschiede zu klären. Jede Operation ist ziemlich anders. Der Punkt ist schön HTTP-Methoden zu haben, die klaren, verschiedene Bedeutungen haben.
POST neue Objekte erstellt. Der URI hat keinen Schlüssel; es nimmt einen Nachrichtentext, der das Objekt definiert. SQL Einfügen. [ Bearbeiten Zwar gibt es keinen technischen Grund für POST keinen Schlüssel zu haben, die Leute REST lassen stark vermuten, dass für POST bestimmte Bedeutung hat, wie CREATE, sollte es keinen Schlüssel.]
GET ruft bestehende Objekte. Die URI können haben einen Schlüssel, hängt davon ab, ob Sie tun Singleton GET oder GET-Liste. SQL-Select
PUT aktualisiert ein vorhandenes Objekt. Die URI hat einen Schlüssel; Er nimmt einen Nachrichtentext, der ein Objekt aktualisiert. SQL-Update.
DELETE löscht ein vorhandenes Objekt. Der URI hat einen Schlüssel. SQL löschen.
Können Sie einen Datensatz mit POST aktualisieren statt PUT? Nicht ohne eine gewisse Mehrdeutigkeit eingeführt wird. Verben sollten eindeutige Auswirkungen haben. Ferner haben POST URI keinen Schlüssel, wo PUT einen Schlüssel hat.
Wenn ich Post, erwarte ich ein 201 ERSTELLT. Wenn ich nicht, dass bekommen, ist etwas falsch. Ebenso, wenn ich PUT, erwarte ich eine 200 OK. Wenn ich nicht, dass bekommen, etwas falsch ist.
Ich nehme an, Sie auf einige Unklarheiten bestehen könnte, wo POST tut entweder POST oder PUT. Der URI hat, anders zu sein; Auch könnte die zugehörige Meldung unterschiedlich sein. Im Allgemeinen nehmen die REST Leute ihr Stichwort von SQL wo INSERT und UPDATE sind verschiedene Verben.
Sie könnten den Fall, dass UPDATE einfügen soll, wenn der Datensatz vorhanden ist oder nicht aktualisiert, wenn der Datensatz vorhanden ist. Allerdings ist es einfacher, wenn UPDATE bedeutet UPDATE und Versagen zu aktualisieren bedeutet, etwas falsch ist. Eine geheime Fallback zu INSERT macht die Bedienung nicht eindeutig.
Wenn Sie nicht eine RESTful Interface bauen, dann ist es typisch, verwendet nur GET und POST für abrufen und / Update erstellen. Es ist üblich, URI Unterschiede oder Nachrichteninhalt Unterschiede haben zwischen POST zu unterscheiden und PUT, wenn eine Person auf einem Formular klickt. Es ist jedoch nicht sehr sauber, weil der Code, um zu bestimmen hat, wenn Sie in der POST sind = erstellen Fall oder POST = Update Fall.
Andere Tipps
POST hat keine Garantien für Sicherheit oder Idempotenz . Das ist ein Grund für PUT und Löschen -sowohl PUT und DELETE sind idempotent (d, 1 + N identische Anfragen haben das gleiche Endergebnis wie nur 1 Anfrage).
PUT für verwendet Einstellung der Zustand einer Ressource zu einem bestimmten URI. Wenn Sie eine senden POST Anfrage auf eine Ressource zu einem bestimmten URI, , dass Ressource nicht sein ersetzt durch die Inhalt. Allenfalls sollte es sein angehängt . Aus diesem Grunde POST ist nicht idempotent-im Fall von BEITRäGEN anhängen, wird jede Anforderung an die Ressource hinzufügen (zum Beispiel Posten neue Nachricht an ein Diskussionsforum jedes Mal).
Löschen dass eine Ressource zu einem bestimmten URI vom Server entfernt wird, sicherzustellen, verwendet. POST sollte in der Regel nicht zum Löschen verwendet werden, außer für den Fall von einreichenden eine Anfrage zu löschen. Auch hier wäre die URI der Ressource, die Sie in diesem Fall POST nicht den URI für die Ressource sollten Sie löschen möchten. Jede Ressource, für die Beiträge zu schreiben ist eine Ressource, die gesendeten Daten akzeptiert sich anhängen, fügen Sie zu einer Sammlung, oder auf andere Art und Weise zu verarbeiten.
HEAD wenn alle um dich kümmern verwendet die Header einer GET-Anforderung ist und Sie nicht wollen, Bandbreite auf den eigentlichen Inhalt verschwenden. Das ist schön zu haben.
Warum brauchen wir mehr als POST? Es ermöglicht es, Daten in beiden Richtungen fließen kann, also warum benötigt würde GET? Die Antwort ist im Grunde die gleiche wie für Ihre Frage. Durch die Standardisierung können die grundlegenden Erwartungen der verschiedenen Methoden andere Prozesse besser wissen, was zu tun ist.
Zum Beispiel, Caching Proxy dazwischen eine bessere Chance hat, die richtige Sache zu tun.
Denken Sie HEAD zum Beispiel. Wenn der Proxy-Server weiß, was HEAD bedeutet, dann kann es das Ergebnis aus einer früheren GET-Anfrage verarbeiten, um die richtige Antwort auf eine HEAD-Anforderung zu liefern. Und es kann wissen, dass POST, PUT und DELETE sollten nicht zwischengespeichert werden.
Niemand kann die Art der Antwort gepostet ich suchte so werde ich versuchen, die Punkte selbst zusammenzufassen.
„RESTful Web Services“ Kapitel 8 Abschnitt „Overloading POST“ lautet: „. Wenn Sie ohne PUT tun wollen und vollständig löschen, es völlig RESTful ist sicher Operationen auf Ressourcen durch GET zu belichten, und alle anderen Operationen durch überladene POST Doing dies verstößt gegen meine ressourcenorientierte Architektur, aber es entspricht die weniger restriktiven Regeln von REST. "
Kurz gesagt, ersetzt PUT / DELETE für POST die API schwieriger macht, um zu lesen und PUT / DELETE Anrufe sind nicht mehr Idempotent .
In einem Wort:
Idempotenz
In ein paar Worten:
GET = safe + Idempotent
PUT = Idempotent
DELETE = Idempotent
POST = weder sicher oder Idempotent
‚Idempotent‘ nur bedeutet, dass Sie es über tun können, und immer wieder, und es wird immer tun genau das Gleiche.
Sie können eine PUT (Update) Neuausstellung oder Anfrage so oft löschen, wie Sie wollen, und es wird die gleiche Wirkung, jedes Mal, haben jedoch die gewünschte Wirkung einer Ressource ändern wird, damit es nicht in Betracht gezogen wird ‚sicher‘.
Eine POST-Anforderung sollte eine neue Ressource mit jeder Anforderung erstellen, dh die Wirkung anders sein wird, jedes Mal. Daher ist POST nicht sicher oder Idempotent betrachtet.
Methoden wie GET und HEAD sind nur Operationen und werden daher als ‚sicher‘ aswell als idempotent lesen.
Dies ist eigentlich ein ziemlich wichtiges Konzept, weil es eine Standard / konsistente Art und Weise liefert HTTP-Transaktionen zu interpretieren; Dies ist besonders nützlich in einem Sicherheitskontext.
Nicht alle Hoster nicht PUT unterstützen, DELETE.
, fragte ich diese Frage in einer idealen Welt, die wir alle Verben haben würde, aber ....:
HEAD ist wirklich nützlich für die Bestimmung dessen, was eines Servers gegeben Uhr (innerhalb der 1 Sekunde genau oder das Netzwerk Umlaufzeit, je nachdem, was höher ist) eingestellt wird. Es ist auch toll für das Erhalten Futurama Zitate von Slashdot:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
cURL , -I ist die Option für eine HEAD-Anfrage ausführt. Um das aktuelle Datum und die Uhrzeit von einem bestimmten Server zu bekommen, nur das tun,
curl -I $server | grep ^Date
Mehrdeutigkeit zu begrenzen, die für eine bessere / einfachere Wiederverwendung unseres einfachen REST-APIs ermöglichen.
könnten Sie verwenden nur GET und POST, aber dann verlieren Sie auf einige der Präzision und Klarheit aus, die bringen PUT und DELETE. POST ist eine Wildcard-Operation, die etwas bedeuten könnte. PUT und DELETE Verhalten ist sehr gut definiert. Wenn Sie einen Ressource-Management-API denken dann GET, PUT und wahrscheinlich 80% -90% der benötigten Funktionalität abdecken DELETE. Wenn Sie sich selbst begrenzen GET und POST dann 40% bis 60% Ihrer api ist das schlecht angegeben POST abgerufen werden.
Web-Anwendungen mit GET und POST ermöglichen Benutzern, Ansicht zu erstellen, ändern und ihre Daten zu löschen, sondern tun dies auf einer Ebene über den HTTP-Befehle ursprünglich für diese Zwecke erstellt. Eine der Ideen hinter REST ist eine Rückkehr zu der ursprünglichen Absicht der Gestaltung des Web, wobei es bestimmte HTTP-Operationen für jedes CRUD Verb.
Auch kann der HEAD-Befehl verwendet werden, um die Benutzererfahrung für (potenziell große) Datei-Downloads zu verbessern. Sie rufen HEAD, um herauszufinden, wie groß die Antwort sein wird, und rufen Sie dann GET, um tatsächlich den Inhalt abgerufen werden.
Sehen Sie die folgenden Link für ein anschauliches Beispiel. Er schlägt vor, auch eine Möglichkeit, die Optionen http-Methode zu verwenden, die noch nicht hier diskutiert worden ist.
Es gibt http Erweiterungen wie WebDAV, die funktionell zusätzlich benötigen.
Der Webserver Krieg aus den früheren Tagen wahrscheinlich verursacht.
HTTP 1.0 im Jahr 1996 geschrieben, wurden nur GET, HEAD und POST . Aber wie Sie in Anhang D sehen können, Anbieter begonnen, ihre hinzufügen eigene Sachen. Also, zu halten HTTP kompatibel, waren sie gezwungen, HTTP 1.1 im Jahr 1999 zu machen .
Allerdings HTTP / 1.0 nicht ausreichend berücksichtigt die Auswirkungen von hierarchischen Proxies, Caching, die Notwendigkeit für persistente Verbindungen oder virtuelle Hosts. Darüber hinaus ist die Proliferation von unvollständig implementierter Anwendungen selbst aufrufen „HTTP / 1.0“ hat eine Protokollversion ändern, um notwendig für zwei kommunizierenden Anwendungen jeweils andere wahre Fähigkeiten zu bestimmen.
Diese Spezifikation definiert das Protokoll als „HTTP / 1.1“. Dieses Protokoll umfasst strengere Anforderungen als HTTP / 1.0, um zuverlässige Umsetzung ihrer Funktionen zu gewährleisten.
GET, PUT, DELETE und POST sind Überbleibsel aus einer Zeit, als Studenten im zweiten Jahr gedacht, dass eine Web-Seite ein paar hoighty-toity Prinzipien reduziert werden.
Heutzutage sind die meisten Web-Seiten sind zusammengesetzte Entitäten, die einige oder alle dieser primitiven Operationen enthalten. Zum Beispiel könnte eine Seite Formen hat für die Anzeige oder Kundeninformationen zu aktualisieren, die vielleicht eine Reihe von Tabellen umfassen.
Ich verwende in der Regel $ _REQUEST [] in php, nicht wirklich kümmern, wie die Information angekommen. Ich würde wählen, GET oder PUT-Methoden basieren auf Effizienz, nicht die zugrunde liegende (multiple) Paradigmen.
