it-swarm.com.de

Welches HTTP-Verb soll ich verwenden, um eine Aktion in einem REST Webdienst) auszulösen?

Ich implementiere einen RESTful-Webdienst und eine der verfügbaren Aktionen ist reload. Es wird verwendet, um Konfigurationen, Cache usw. neu zu laden.

Wir haben mit einem einfachen GET zu einem URI wie diesem begonnen: ${path}/cache/reload (es werden keine Parameter übergeben, nur der URI wird aufgerufen). Mir ist bekannt, dass Daten nicht mit einer GET-Anfrage geändert werden sollten.

Welches Verb ist das richtige, um eine Aktion/einen Befehl in einem RESTful-Webdienst aufzurufen?

Das Neuladen ist ein Befehl des Webdienstes REST], der seinen eigenen Cache/Konfiguration/etc. Neu lädt. Es ist keine Methode, die Informationen an den Client zurückgibt.

Wahrscheinlich ist das, was ich versuche, nicht REST, aber es ist immer noch etwas, das auf diese Weise getan werden muss. Das reload Die Methode war nur ein echtes Beispiel, das im Umfang der Anwendung Sinn macht, und die meisten Antworten konzentrierten sich darauf. Tatsächlich musste ich nur wissen, welches Verb eine Aktion auslösen soll, die kein CRUD ausführt, aber dennoch Daten/Status ändert .

Ich fand diese detaillierte Antwort zu Stack Overflow zu folgendem Thema: https://stackoverflow.com/questions/16877968/

91
Renato Dinhani

Ich glaube nicht, dass es ein richtiges Verb für diese Aktion gibt, da diese Transaktion nicht wirklich "RESTful" ist. Die "s" und "t" stehen für "State Transfer" und hier wird nichts übertragen. Oder anders ausgedrückt: Nach der strengsten Definition werden Verben wie PUT und POST immer mit einem Substantiv verwendet und "reload" hat nur das Verb.

Dieses Nachladen ist möglicherweise nicht RESTful, aber es kann dennoch nützlich sein, und Sie müssen nur einen Weg wählen, um es zu tun und damit zu leben oder zu erklären, dass es ungewöhnlich ist. GET ist wahrscheinlich das einfachste. Die Kommentare enthalten jedoch einiges an Skepsis. Sie sollten sich also überlegen, ob diese Nachladeaktion erforderlich ist oder nicht, da etwas anderes nicht ganz das tut, was es tun sollte.

26
Sean Redmond

Wenn Sie RESTful sein möchten, denken Sie nicht an das Verb, um eine Aktion auszuführen, sondern an state, in dem sich die Ressource befinden soll, nachdem der Client etwas getan hat.

Wenn Sie also eines Ihrer obigen Beispiele verwenden, haben Sie eine E-Mail-Warteschlange, die E-Mails sendet. Sie möchten, dass der Client diese E-Mail-Warteschlange in den Status "Angehalten" oder "Angehalten" versetzt.

Der Client legt dem Server für diese Ressource einen neuen Status zu. Es kann so einfach sein wie dieser JSON

PUT http://myserver.com/services/email_service HTTP/1.1
Content-Type: text/json

{"status":"paused"}

Der Server findet heraus, wie er vom aktuellen Status (z. B. "Ausführen") zum Status/Status "Angehalten" gelangt.

Wenn der Client ein GET für die Ressource ausführt, sollte er den aktuellen Status zurückgeben (z. B. "pausiert").

Der Grund dafür und warum REST so mächtig sein kann, ist, dass Sie das WIE verlassen, um auf dem Server in diesen Zustand zu gelangen.

Der Client sagt nur "Dies ist der Zustand, in dem Sie sich jetzt befinden sollten" und der Server findet heraus, wie dies erreicht werden kann. Es könnte ein einfacher Flip in einer Datenbank sein. Möglicherweise sind Tausende von Aktionen erforderlich. Dem Kunden ist das egal und er muss es nicht wissen.

Sie können also komplett neu schreiben/gestalten, wie der Server das macht, und der Client kümmert sich nicht darum. Der Client muss nur die verschiedenen Zustände (und deren Darstellungen) einer Ressource kennen, nicht die Interna.

78
Cormac Mulhall

Einige der anderen Antworten, einschließlich der akzeptierten, empfehlen Ihnen, ein GET zu verwenden (wenn auch nicht sehr enthusiastisch).

Ich stimme dir nicht zu.

Zuallererst sind alle anderen, die Ihnen sagen, dass dies nicht ideal und nicht wirklich RESTful ist, richtig. In einem ordnungsgemäßen RESTful-Szenario bearbeiten Sie Ressourcen auf dem Server und fügen diese Ressourcen hinzu, aktualisieren sie, löschen sie, rufen sie ab usw. Ein PUT sollte eine Nutzlast senden, die angibt, wie die Ressource sein soll, wenn die Anforderung abgeschlossen ist, und POST sollte eine Nutzlast senden, die eine Ressource darstellt, die dem Server hinzugefügt werden soll. Und ein GET sollte zurückkehren eine Ressource auf dem Server.

Sie haben einen RPC (Remote Procedure Call), der nicht RESTful ist - Sie möchten etwas auf dem Server tun. Wenn Sie also versuchen, eine reine RESTful-API zu erstellen, sollten Sie überlegen, was Sie tun.

Das heißt, manchmal müssen Sie die Regeln ein wenig biegen. Insbesondere wenn Sie eine interne API entwickeln, die nicht der Öffentlichkeit zugänglich ist, können Sie entscheiden, dass sich der Kompromiss lohnt.

Wenn Sie dies tun, würde ich einen PUT oder POST empfehlen, je nachdem, ob der RPC idempotent ist oder nicht.

Im Allgemeinen sagen wir, dass HTTP-PUT SQL UPDATE zugeordnet ist und dass HTTP POST SQL INSERT zugeordnet ist, aber das ist nicht unbedingt richtig. Eine reinere Art zu sagen ist, dass HTTP-PUT idempotent sein sollte und HTTP POST muss nicht sein. Dies bedeutet, dass Sie dieselbe PUT-Anforderung so oft aufrufen können, wie Sie möchten, ohne Nebenwirkungen. Wenn Sie sie einmal aufgerufen haben, ist es harmlos, sie aufzurufen Sie sollten jedoch nicht wiederholt POST Anfragen aufrufen, es sei denn, Sie möchten - jedes POST ändert die Daten auf dem Server erneut.

In Ihrem Fall würde ich einen PUT empfehlen, wenn Sie diese Reload-Funktion benötigen, da dies idempotent klingt. Aber ich möchte Sie trotzdem dringend bitten, darüber nachzudenken, was die anderen darüber gesagt haben, dass sie es überhaupt nicht brauchen.

33
Aaron Greenwald

POST und PUT sind die HTTP-Verben, mit denen eine Entität an einen Webserver gesendet wird. Bei PUT ist die übermittelte Entität die (neue) Darstellung für die Ressource am angegebenen URI, die nicht Ihren Anforderungen entspricht. POST ist für den traditionellen Formular-Handler, bei dem die Entität Zusatzdaten für die Ressource sind. Das ist also der Gewinner. Die Entität würde den Befehl oder die Aktion enthalten (z. B. "action = reload").

Das heißt, der betreffende Befehl sollte wahrscheinlich nicht über eine REST - Schnittstelle verfügbar gemacht werden. Es scheint, dass die Notwendigkeit eines "Neuladens" entsteht, da Daten über einen anderen Kanal (z. B. Dateisystem, geändert werden können). DB-Client). Caches sollten transparent sein. Darüber hinaus sollten HTTP-Anforderungen atomar sein und sogar Nachrichten berücksichtigen, die über andere Kanäle gesendet werden. Das Anbieten eines "Reload" -Befehls für Konfigurationseinstellungen scheint eine unnötige Komplexität zu sein und erfordert ein sprödes Design. reload "zur Bereinigung nach einem Update über einen anderen Kanal ist fehlerhaft, da ein Kanal nicht die gesamte Konversation enthält. Betrachten Sie stattdessen einen der folgenden Punkte:

  • aktualisierungen vollständig über REST vornehmen
  • setzen Sie die Befehle dem anderen Kanal aus
  • automatisierung der Aktionen

Einige dieser Optionen sind möglicherweise nicht realisierbar, je nachdem, welche anderen Einschränkungen bestehen.

Siehe auch " PUT vs POST in REST " ".

6
outis

Ich würde argumentieren, warum eine Kundenanfrage explizit einen Anruf tätigen müsste, um so etwas zu aktualisieren. Es klingt so, als ob dies entweder eine versteckte Logik bei einer typischeren Implementierung von GET sein sollte (d. H. Pull-Daten, aber der Dienst führt eine Aktualisierung der Daten durch, bevor sie abgerufen werden) oder durch einen anderen Trigger im Backend vom Client weg.

Schließlich müssten die Daten/Konfigurationen nur bei nachfolgenden Aufrufen aktuell sein, sodass ich mich eher einem faulen als einem eifrigen Aufruf für eine Datenaktualisierung zuwenden würde. Natürlich gehe ich hier von viel aus, aber ich würde einen Schritt zurücktreten, um die Notwendigkeit eines solchen expliziten und eigenständigen Anrufs neu zu bewerten.

4
Thomas Stringer

Warum behandeln Sie die Aktion nicht wie eine Ressource? Da Sie also den Cache aktualisieren möchten, würden Sie POST eine neue Aktion in Ihrem System.

Für Puristen könnte man dafür eine eigene URL haben. Beachten Sie, dass Sie dies erweitern und die tatsächlichen Aktionen in einer Datenbank (oder einem beliebigen Speicher) mit Datum, Status, Benutzer usw. protokollieren können. Nur meine Gedanken hier.

Generische systemweite Operation/Aktionen/{Aktion}

Operation spezifisch für einen Ressourcentyp/Aktionen/{Ressource}/{Aktion}

Operation spezifisch für eine Ressource/Aktionen/{Ressource}/{ID}/{Aktion}

In Ihrem Fall ist der Cache wahrscheinlich systemweit/action/reload_cache

3
Isometriq

Welches HTTP-Verb soll ich verwenden, um eine Aktion in einem REST Webdienst) auszulösen?

Wenn Sie die Details eines REST -Dienstes) betrachten, ist es oft nützlich, diese Heuristik zu berücksichtigen: Wie würden Sie dies mit einer Website implementieren?

HTML kann nur nativ GET- und POST - Anfragen beschreiben. Wir können also mit der Suche dort beginnen.

Ist GET angemessen? Um diese Frage zu beantworten, müssen wir über die Annahmen nachdenken, die Clients und Zwischenkomponenten über GET treffen dürfen. Die Semantik von GET ist sicher

der Client fordert keine Statusänderung auf dem Origin-Server an und erwartet diese auch nicht, wenn eine sichere Methode auf eine Zielressource angewendet wird. Ebenso wird nicht erwartet, dass eine angemessene Verwendung einer sicheren Methode den Origin-Server schädigt, Eigentum verliert oder ungewöhnlich belastet.

Die Implikation ist daher, dass es den Clients und Zwischenkomponenten freigestellt ist, eine GET-Anfrage so oft wie nötig aufzurufen, um ihre eigenen Bedenken zu befriedigen. Spinnen können wahllos Ressourcen abrufen, um ihre Indizes zu aktualisieren. Caches können vorab abgerufen werden. In einem unzuverlässigen Netzwerk können verlorene Nachrichten so oft wie nötig wiederholt werden, um mindestens eine Antwort sicherzustellen.

Es wird verwendet, um Konfigurationen, Cache usw. neu zu laden.

Wenn dies teure Dinge sind, möchten Sie möglicherweise nicht, dass die Kunden diese Anfragen nach eigenem Ermessen stellen.

POST hingegen ist praktisch nicht eingeschränkt - dies reduziert die Annahmen, die generische Clients treffen dürfen, erheblich. Sie erhalten keine Komponenten, die spekulative POST - Anfragen stellen, weil dies fehlerhaft wäre - nichts im Standard sagt, dass dies in Ordnung ist.

PUT, PATCH, DELETE... Dies sind unsichere Methoden mit einer spezifischeren Semantik als POST; Ob sie angemessen sind oder nicht, hängt von Ihrem Ressourcenmodell ab.

Eine wichtige Idee, die Sie berücksichtigen sollten, ist, dass die HTTP-Methoden in die Dokumentdomäne gehören (siehe Jim Webbers Vortrag 2011 ). Die von Ihnen beschriebenen Effekte sind wahrscheinlich nicht Teil der Dokumentdomäne, sondern eher Seite Effekte, die beim Ändern der Dokumente aufgerufen werden. Das gibt Ihnen viel Freiheit bei der Organisation Ihrer Dokumente, um die Arbeit zu erledigen.

0
VoiceOfUnreason