it-swarm.com.de

REST API mit POST anstelle von GET

Nehmen wir an, ein Dienst bietet einige Funktionen, die ich folgendermaßen verwenden kann:

GET /service/function?param1=value1&param2=value2

Ist es richtig zu sagen, dass ich es mit einer POST query verwenden kann?

POST /service/function { param1 : value1, param2 : value2 }

Sind diese beiden Abfragen gleich? Kann ich auf jeden Fall die zweite Variante verwenden oder sollte in der Dokumentation explizit angegeben werden, dass ich sowohl GET als auch POST Abfragen verwenden kann?

50
hank

Sie können API nicht mit POST oder GET verwenden, wenn sie nicht für den separaten Aufruf mit diesen Methoden erstellt wurden. Wie wenn deine API sagt

/service/function?param1=value1&param2=value2

der Zugriff erfolgt mit der Methode GET. Dann können Sie es nicht mit der POST -Methode aufrufen, wenn es vom Ersteller nicht als POST -Methode angegeben wurde. Wenn du das tust, hast du vielleicht 405 Method not allowed Status.

Im Allgemeinen müssen Sie in der POST -Methode den Inhalt im angegebenen Format senden, das in content-type Header zum Beispiel. application/json für JSON-Daten.

Danach wird der Anforderungshauptteil am Serverende deserialisiert. Sie müssen also die serialisierten Daten vom Client übergeben und es wird vom Service-Entwickler entschieden.

Im Allgemeinen wird GET verwendet, wenn der Server einige Daten an den Client zurückgibt und keine Auswirkungen auf den Server hat, während POST zum Erstellen einer Ressource auf dem Server verwendet wird. Also sollte es im Allgemeinen nicht dasselbe sein.

32
Sachin

Nur um zu überprüfen, hat REST bestimmte Eigenschaften, denen ein Entwickler folgen sollte, um es zu machen RESTful:

Was ist REST?

Laut Wikipedia:

Der Architekturstil REST beschreibt die folgenden sechs Einschränkungen, die auf die Architektur angewendet werden, wobei die Implementierung der einzelnen Komponenten frei gestaltet werden kann:

  • Client-Server: Server beschäftigen sich nicht mit der Benutzeroberfläche oder dem Benutzerstatus, sodass Server einfacher und skalierbarer sind.
  • Statuslos: Die Client-Server-Kommunikation wird weiterhin dadurch eingeschränkt, dass zwischen Anforderungen kein Client-Kontext auf dem Server gespeichert wird.
  • Zwischenspeicherbar: Antworten müssen sich implizit oder explizit als zwischenspeicherbar definieren, um zu verhindern, dass Clients veraltete oder unangemessene Daten als Antwort auf weitere Anforderungen wiederverwenden.
  • Layered System: Ein Client kann normalerweise nicht erkennen, ob er direkt mit dem Endserver oder mit einem Vermittler verbunden ist. Zwischenserver können die Skalierbarkeit des Systems verbessern, indem sie den Lastenausgleich aktivieren und gemeinsam genutzte Caches bereitstellen.
  • Code on demand (optional): Server können die Funktionalität eines Clients durch die Übertragung von ausführbarem Code vorübergehend erweitern oder anpassen.
  • Einheitliche Schnittstelle: Die im Folgenden beschriebene einheitliche Schnittstelle zwischen Clients und Servern vereinfacht und entkoppelt die Architektur, sodass sich die einzelnen Teile unabhängig voneinander entwickeln können. (d. h. HTTP GET, POST, PUT, PATCH, DELETE)

Was die Verben tun sollen

SO Benutzer Daniel Vasallo hat die Verantwortlichkeiten dieser Methoden in der Frage gut dargelegt Grundlegendes zu REST: Verben, Fehlercodes und Authentifizierung:

Beim Umgang mit einem Collection-URI wie: http://example.com/resources/

GET: Listet die Mitglieder der Sammlung mit ihren Mitglieds-URIs zur weiteren Navigation auf. Listen Sie zum Beispiel alle Autos auf, die zum Verkauf stehen.

PUT: Bedeutung definiert als "die gesamte Sammlung durch eine andere Sammlung ersetzen".

POST: Erstellen Sie einen neuen Eintrag in der Sammlung, wobei die ID automatisch von der Sammlung zugewiesen wird. Die erstellte ID wird normalerweise als Teil der von dieser Operation zurückgegebenen Daten einbezogen.

DELETE: Bedeutung definiert als "gesamte Sammlung löschen".

Um Ihre Frage zu beantworten:

Ist es richtig zu sagen, dass ich es mit einer POST query verwenden kann? ...

Sind diese beiden Abfragen gleich? Kann ich auf jeden Fall die zweite Variante verwenden oder sollte in der Dokumentation explizit angegeben werden, dass ich sowohl GET als auch POST Abfragen verwenden kann?

Wenn Sie einen normalen alten RPC-API-Aufruf schreiben, können sie technisch austauschbar sein, solange sich die Seite des Verarbeitungsservers nicht zwischen beiden Aufrufen unterscheidet. Damit der Aufruf jedoch REST-fähig ist, muss der Aufruf des Endpunkts über die Methode GET eine bestimmte Funktionalität haben (dh Ressourcen abrufen), die von der Methode POST (dh neue Ressourcen erstellen).

Randnotiz: Es gibt einige Debatten darüber, ob POST auch zum Aktualisieren von Ressourcen verwendet werden darf oder nicht ... obwohl ich das nicht kommentiere, sage ich es nur Sie einige Leute haben ein Problem mit diesem Punkt.

57
Kristian

Ich verwende POST body für alle nicht trivialen und branchenüblichen Apps aus folgenden Gründen:

  1. Sicherheit - Wenn wir GET mit Abfragezeichenfolgen und https verwenden, können die Abfragezeichenfolgen in Serverprotokollen gespeichert und als Verweislinks weitergeleitet werden. Beide sind jetzt für Server-/Netzwerkadministratoren sichtbar und die nächste Domain, zu der der Benutzer nach dem Verlassen Ihrer App gegangen ist. Wenn wir also eine Anfrage senden, die vertrauliche personenbezogene Daten wie den Namen eines Kunden enthält, ist dies möglicherweise nicht erwünscht.
  2. Maximale URL-Länge - Kein großes Problem, aber bei einigen Browsern ist die Länge begrenzt. Wenn wir also mehrere Elemente in unserer URL haben, z. B. Abfrage, Seitenwechsel, zurückzugebende Felder usw.
  3. Post wird nicht standardmäßig zwischengespeichert. Einige sagen, dass das Zwischenspeichern gewünscht wird; Wie oft wird jedoch genau derselbe Satz von Suchkriterien für das genaue Objekt für den genauen Kunden auftreten, bevor das Zeitlimit für den Cache überschritten wird?

Übrigens, ich habe auch die Felder in meinen POST body eingefügt, da ich meine Feldnamen möglicherweise nicht preisgeben möchte. Sicherheit ist wie eine Zwiebel, viele Schichten und bringt uns zum Weinen!

38
Scott Peal

Denk darüber nach. Wenn Ihr Client eine GET-Anforderung an einen URI X sendet, sagt er dem Server Folgendes: "Ich möchte eine Darstellung der Ressource, die sich auf X befindet, und dieser Vorgang sollte nichts auf dem Server ändern." In einer PUT-Anfrage heißt es: "Ich möchte, dass Sie die in X befindliche Ressource durch die neue Entität ersetzen, die ich Ihnen im Hauptteil dieser Anfrage gebe." In einer DELETE-Anforderung heißt es: "Ich möchte, dass Sie alle Ressourcen löschen, die sich in X befinden." Ein PATCH sagt: "Ich gebe Ihnen diesen Unterschied, und Sie sollten versuchen, ihn auf die Ressource bei X anzuwenden und mir mitzuteilen, ob er erfolgreich ist." Aber ein POST sagt: "Ich sende Ihnen diese Daten, die der Ressource bei X untergeordnet sind, und wir haben eine vorherige Vereinbarung getroffen, was Sie damit tun sollen."

Wenn Sie nicht irgendwo dokumentiert haben, dass die Ressource einen POST erwartet und etwas damit tut, ist es nicht sinnvoll, einen POST an sie zu senden, damit sie sich so verhält ein GET.

REST stützt sich auf das standardisierte Verhalten des zugrunde liegenden Protokolls, und POST ist genau die Methode, die für eine nicht standardisierte Aktion verwendet wird. Das Ergebnis einer GET-, PUT- und DELETE-Anforderung ist im Standard klar definiert, nicht jedoch POST. Das Ergebnis eines POST ist dem Server untergeordnet. Wenn also nicht dokumentiert ist, dass Sie POST verwenden können, müssen Sie davon ausgehen, dass dies nicht möglich ist.

9
Pedro Werneck

Es ist schön, dass REST) den HTTP-Verben (wie sie definiert sind) Bedeutung verleiht, aber ich bin lieber mit Scott Peal einverstanden.

Hier ist auch ein Punkt aus der erweiterten Erklärung von WIKI zu POST-Anfrage :

Es gibt Zeiten, in denen HTTP GET selbst für das Abrufen von Daten weniger geeignet ist. Ein Beispiel hierfür ist, wenn eine große Menge von Daten in der URL angegeben werden müsste. Bei Browsern und Webservern kann die Länge der URL, die ohne Kürzung oder Fehler verarbeitet werden soll, begrenzt sein. Die prozentuale Kodierung reservierter Zeichen in URLs und Abfragezeichenfolgen kann deren Länge erheblich erhöhen, und während Apache HTTP Server bis zu 4.000 Zeichen in einer URL verarbeiten kann, [5] ist Microsoft Internet Explorer in jeder URL auf 2.048 Zeichen beschränkt. [6] Ebenso sollte HTTP GET nicht verwendet werden, wenn vertrauliche Informationen wie Benutzernamen und Kennwörter zusammen mit anderen Daten übermittelt werden müssen, damit die Anforderung abgeschlossen werden kann. Selbst wenn HTTPS verwendet wird, um zu verhindern, dass die Daten während der Übertragung abgefangen werden, enthalten der Browserverlauf und die Protokolle des Webservers wahrscheinlich die vollständige URL im Klartext, die möglicherweise angezeigt wird, wenn eines der Systeme gehackt wird. In diesen Fällen sollte HTTP POST verwendet werden. [7]

Ich kann nur dem REST Team empfehlen, eine sicherere Verwendung des HTTP-Protokolls in Betracht zu ziehen, um zu vermeiden, dass Verbraucher mit nicht sicheren "guten Praktiken" zu kämpfen haben.

4
user7071799

In REST hat jedes HTTP-Verb seinen Platz und seine Bedeutung.

Beispielsweise,

  • Mit GET werden die Ressourcen abgerufen, auf die in der URL verwiesen wird.

  • POST weist das Backend an, eine Ressource des Typs zu erstellen, auf den in der URL verwiesen wird. Sie können die Operation POST mit Parametern oder zusätzlichen Daten im Hauptteil des Aufrufs POST ergänzen.

In Ihrem Fall sollte es sich also um eine GET-Operation anstelle einer POST) - Operation handeln, da Sie daran interessiert sind, die Informationen mithilfe einer Abfrage abzurufen.

Dies Wiki kann helfen um die Dinge weiter zu klären.

Ich hoffe das hilft!

3
Ming Chan