it-swarm.com.de

REST API - warum PUT DELETE verwenden POST GET?

Daher habe ich einige Artikel zum Erstellen von REST APIs durchgesehen. Einige schlagen vor, alle Arten von HTTP-Anforderungen zu verwenden: wie PUTDELETEPOSTGET. Wir würden zum Beispiel index.php erstellen und die API folgendermaßen schreiben:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

OK, selbstverständlich - Ich weiß (noch) nicht viel über Webdienste. Aber wäre es nicht einfacher, einfach [~ # ~] json [~ # ~] Objekt durch reguläres POST oder GET zu akzeptieren (das wäre enthalten den Methodennamen und alle Parameter) und antworten dann ebenfalls in JSON. Wir können einfach über die PHP-Befehle json_encode() und json_decode() serialisieren/deserialisieren und mit diesen Daten arbeiten, ohne uns mit verschiedenen HTTP-Anforderungsmethoden auseinandersetzen zu müssen.

Vermisse ich etwas?

UPDATE 1:

Ok - nachdem ich verschiedene APIs durchgesehen und viel über XML-RPC gelernt habe, JSON-RPC, [~ # ~] soap [~ # ~], [~ # ~] Rest [~ # ~] Ich bin zu dem Schluss gekommen, dass diese Art von API einwandfrei ist. Tatsächlich verwendet der Stapelaustausch auf ihren Websites so ziemlich diesen Ansatz, und ich glaube, diese Leute wissen, was sie tun Stapelaustausch-API .

148
Stann

Die Idee von REpräsentational State Tbei der Übertragung geht es nicht darum, auf möglichst einfache Weise auf Daten zuzugreifen.

Sie haben vorgeschlagen, Post-Requests für den Zugriff auf JSON zu verwenden. Dies ist eine absolut gültige Methode für den Zugriff auf/die Bearbeitung von Daten.

REST ist eine Methode für den sinnvollen Zugriff auf Daten. Wenn Sie eine Anforderung in REST sehen, sollte sofort ersichtlich sein, was mit den Daten geschieht.

Beispielsweise:

GET: /cars/make/chevrolet

wird wahrscheinlich eine Liste von chevy Autos zurückgeben. Eine gute REST api könnte sogar einige Ausgabeoptionen in den Querystring integrieren, wie ?output=json oder ?output=html, mit dessen Hilfe der Accessor entscheiden kann, in welchem ​​Format die Informationen codiert werden sollen.

Nach einigem Überlegen, wie die Datentypisierung in eine REST API sinnvoll integriert werden kann, bin ich zu dem Schluss gekommen, dass der beste Weg, den Datentyp explizit anzugeben, über die bereits vorhandene Dateierweiterung wie z wie .js, .json, .html, oder .xml. Eine fehlende Dateierweiterung weist standardmäßig das Standardformat auf (z. B. JSON). Eine nicht unterstützte Dateierweiterung kann ein 501 Not Implemented Statuscode .

Ein anderes Beispiel:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

wird wahrscheinlich einen neuen Chevy Malibu in der Datenbank mit den zugehörigen Farben erstellen. Ich sage wahrscheinlich , da die REST api nicht direkt mit der Datenbankstruktur zusammenhängen muss. Es ist nur eine Maskierungsschnittstelle, damit die wahren Daten geschützt werden (denken Sie an Accessoren und Mutatoren für eine Datenbankstruktur).

Nun müssen wir uns dem Thema Idempotenz zuwenden. Normalerweise implementiert REST ROH über HTTP. HTTP verwendet GET, PUT, POST und DELETE für die Anforderungen.

Eine sehr vereinfachte Implementierung von REST could verwendet das folgende CRUD-Mapping:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

Bei dieser Implementierung gibt es ein Problem: Post ist als nicht idempotente Methode definiert. Dies bedeutet, dass nachfolgende Aufrufe derselben Post-Methode zu unterschiedlichen Serverstatus führen. Get, Put und Delete sind idempotent. Dies bedeutet, dass ein mehrmaliger Aufruf zu einem identischen Serverstatus führen sollte.

Dies bedeutet, dass eine Anfrage wie:

Delete: /cars/oldest

könnte tatsächlich implementiert werden als:

Post: /cars/oldest?action=delete

Wohingegen

Delete: /cars/id/123456

führt zu demselben Serverstatus, wenn Sie ihn einmal oder 1000 Mal aufrufen.

Eine bessere Möglichkeit zum Entfernen des Elements oldest besteht darin, Folgendes anzufordern:

Get: /cars/oldest

und benutze das ID aus den resultierenden Daten, um eine delete Anfrage zu stellen:

Delete: /cars/id/[oldest id]

Ein Problem mit dieser Methode wäre, wenn ein anderes /cars Element wurde zwischen hinzugefügt, als /oldest wurde angefordert und als delete ausgestellt wurde.

195
zzzzBov

Dies ist eine Sicherheits- und Wartbarkeitsfrage.

sichere Methoden

Wann immer möglich, sollten Sie "sichere" (unidirektionale) Methoden wie GET und HEAD) verwenden, um die potenzielle Sicherheitsanfälligkeit zu begrenzen.

idempotente Methoden

Wann immer möglich, sollten Sie idempotente Methoden wie GET, HEAD, PUT und DELETE verwenden, die keine Nebenwirkungen haben und daher weniger fehleranfällig/leichter zu kontrollieren sind.

Quelle

38
markus

Kurz gesagt, REST betont Substantive gegenüber Verben. Wenn Ihre API komplexer wird, fügen Sie mehr Dinge hinzu als mehr Befehle.

24
Neil

Du hast gefragt:

wäre es nicht einfacher, JSON-Objekte einfach über $ _POST zu akzeptieren und dann auch in JSON zu antworten?

Aus der Wikipedia auf REST :

RESTful-Anwendungen maximieren die Verwendung der bereits vorhandenen, genau definierten Schnittstelle und anderer integrierter Funktionen, die vom ausgewählten Netzwerkprotokoll bereitgestellt werden, und minimieren die Hinzufügung neuer anwendungsspezifischer Funktionen

Soweit ich (wenig) gesehen habe, wird dies meiner Meinung nach in der Regel dadurch erreicht, dass die vorhandenen HTTP-Verben optimal genutzt werden und ein möglichst leistungsfähiges und selbstverständliches URL-Schema für Ihren Dienst erstellt wird.

Benutzerdefinierte Datenprotokolle (auch wenn sie auf Standardprotokollen wie SOAP oder JSON aufbauen) werden nicht empfohlen und sollten minimiert werden, um der REST - Ideologie bestmöglich zu entsprechen.

SOAP RPC over HTTP hingegen fordert jeden Anwendungsentwickler auf, ein neues und willkürliches Vokabular von Substantiven und Verben (z. B. getUsers (), savePurchaseOrder (...)) zu definieren, das normalerweise dem HTTP-Verb 'POST' überlagert wird. Dadurch werden viele der vorhandenen HTTP-Funktionen wie Authentifizierung, Zwischenspeicherung und Aushandlung von Inhaltstypen ignoriert, und der Anwendungsdesigner kann möglicherweise viele dieser Funktionen im neuen Vokabular neu erfinden.

Die tatsächlichen Objekte, mit denen Sie arbeiten, können in einem beliebigen Format vorliegen. Die Idee ist, so viel HTTP wie möglich wiederzuverwenden, um Ihre Vorgänge anzuzeigen, die der Benutzer für diese Ressource ausführen möchte (Abfragen, Statusverwaltung/Mutation, Löschen).

Du hast gefragt:

Vermisse ich etwas?

Es gibt viel mehr zu wissen über REST und die URI-Syntax/HTTP-Verben selbst. Zum Beispiel sind einige der Verben idempotent, andere nicht. Ich habe in Ihrer Frage nichts darüber gesehen, also habe ich mich nicht darum gekümmert, mich darauf einzulassen. Die anderen Antworten und Wikipedia haben viele gute Informationen.

Außerdem gibt es viel zu lernen über die verschiedenen Netzwerktechnologien, die auf HTTP aufbauen und die Sie nutzen können, wenn Sie eine wirklich erholsame API verwenden. Ich würde mit der Authentifizierung beginnen.

In Bezug auf die Verwendung der Erweiterung zum Definieren des Datentyps. Ich habe festgestellt, dass die MailChimp-API dies tut, halte dies jedoch nicht für eine gute Idee.

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

Ich höre mich nach einer guten Idee an, denke aber, dass ein "älterer" Ansatz besser ist - mit HTTP-Headern

GET /xxx/cars/1
Accept: application/json

Auch HTTP-Header sind für die datentypübergreifende Kommunikation viel besser (falls jemals jemand sie benötigen würde).

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  
8
Pawel Cioch

Vermisse ich etwas?

Ja. ;-)

Dieses Phänomen tritt aufgrund der einheitlichen Schnittstellenbeschränkung auf. REST verwendet gerne vorhandene Standards, anstatt das Rad neu zu erfinden. Der HTTP-Standard hat sich bereits als hoch skalierbar erwiesen (das Web funktioniert schon eine Weile). Warum sollten wir etwas reparieren, das nicht kaputt ist ?!

Hinweis: Die einheitliche Schnittstellenbeschränkung ist wichtig, wenn Sie die Clients vom Dienst entkoppeln möchten. Es ähnelt dem Definieren von Schnittstellen für Klassen, um diese voneinander zu entkoppeln. Ofc. Hier besteht die einheitliche Schnittstelle aus Standards wie HTTP , MIME-Typen , [~ # ~] uri [~] # ~] , RDF , verknüpfte Datenvokabeln , Hydra-Vokabeln , etc .. .

4
inf3rno

Gute Semantik ist wichtig in der Programmierung.

Die Verwendung weiterer Methoden neben GET/POST ist hilfreich, da dadurch die Lesbarkeit Ihres Codes verbessert und die Wartung vereinfacht wird.

Warum?

Weil Sie wissen, dass GET Daten von Ihrer API abruft. Sie wissen, dass POST Ihrem System neue Daten hinzufügt. Sie wissen, dass PUT Aktualisierungen vornimmt. LÖSCHEN löscht Zeilen usw. usw.

Normalerweise strukturiere ich meine RESTFUL-Webdienste so, dass ich einen Funktionsrückruf erhalte, der das Gleiche wie die Methode heißt.

Ich benutze PHP, also benutze ich function_exists (ich denke, es heißt). Wenn die Funktion nicht existiert, werfe ich eine 405 (METHODE NICHT ERLAUBT).

1
HumbleWebDev

Bill Venners: In Ihrem Blog-Beitrag mit dem Titel "Warum REST Fehlgeschlagen", sagten Sie, dass wir alle vier HTTP-Verben benötigen - GET, POST, PUT und DELETE - und beklagten, dass die Browser-Anbieter nur GET und POST anbieten. "Warum brauchen wir alle vier Verben? Warum reichen GET und POST nicht aus?

Elliotte Rusty Harold: Es gibt vier grundlegende Methoden in HTTP: GET, POST, PUT und DELETE. GET wird die meiste Zeit benutzt. Es wird für alles verwendet, was sicher ist und keine Nebenwirkungen verursacht. GET kann mit einem Lesezeichen versehen, zwischengespeichert, verknüpft und über einen Proxyserver weitergeleitet werden. Es ist eine sehr mächtige Operation, eine sehr nützliche Operation.

POST hingegen ist vielleicht die leistungsstärkste Operation. Es kann alles machen. Es gibt keine Grenzen für das, was passieren kann, und deshalb muss man sehr vorsichtig damit umgehen. Sie können es nicht als Lesezeichen speichern. Sie zwischenspeichern es nicht. Sie holen es nicht vor. Sie können mit einem POST nichts anfangen, ohne den Benutzer zu fragen. Möchten Sie dies tun? Wenn der Benutzer die Taste drückt, können Sie POST= einige Sie werden jedoch nicht alle Schaltflächen auf einer Seite anzeigen und zufällig darauf drücken. Im Gegensatz dazu können Browser alle Links auf der Seite anzeigen und sie vorabholen oder diejenigen, die sie denken, vorabholen werden am ehesten als nächstes verfolgt, und tatsächlich haben einige Browser und Firefox-Erweiterungen sowie verschiedene andere Tools versucht, dies an der einen oder anderen Stelle zu tun.

PUT und DELETE liegen in der Mitte zwischen GET und POST. Der Unterschied zwischen PUT oder DELETE und POST ist, dass PUT und DELETE * idempotent sind, wohingegen POST nicht. PUT und DELETE können bei Bedarf wiederholt werden Angenommen, Sie möchten eine neue Seite auf eine Website hochladen. Angenommen, Sie möchten eine neue Seite unter http://www.example.com/foo.html erstellen, und geben Ihren Inhalt und ein Sie haben es unter dieser URL eingegeben. Der Server erstellt die Seite unter der von Ihnen angegebenen URL. Nehmen wir nun an, dass die Netzwerkverbindung aus irgendeinem Grund unterbrochen wurde. Sie sind sich nicht sicher, ob die Anforderung durchgekommen ist oder nicht. Vielleicht ist es das Netzwerk langsam. Möglicherweise gab es ein Proxy-Server-Problem. Es ist also vollkommen in Ordnung, es erneut zu versuchen oder so oft Sie möchten. Weil es nicht anders ist, dasselbe Dokument zehn Mal an dieselbe URL zu senden, als es einmal abzulegen Dasselbe gilt für DELETE. Sie können etwas zehnmal LÖSCHEN, und das ist dasselbe wie einmaliges Löschen.

Im Gegensatz dazu kann durch POST jedes Mal etwas anderes passieren. Stellen Sie sich vor, Sie verlassen einen Online-Shop, indem Sie auf die Schaltfläche "Kaufen" klicken. Wenn Sie diese POST) Anfrage erneut senden, könnten Sie am Ende ein zweites Mal alles in Ihrem Einkaufswagen kaufen. Wenn Sie sie erneut senden, haben Sie es ein drittes Mal gekauft. Deshalb müssen Browser Seien Sie sehr vorsichtig, wenn Sie POST Vorgänge ohne ausdrückliche Zustimmung des Benutzers wiederholen, da POST bei zweimaliger Ausführung zwei Dinge passieren können, bei dreierlei Mit PUT und DELETE gibt es einen großen Unterschied zwischen null und eins, aber keinen Unterschied zwischen einer und zehn.

Bitte besuchen Sie die URL für weitere Details. http://www.artima.com/lejava/articles/why_put_and_delete.html

Update:

Idempotente Methoden Eine idempotente HTTP-Methode ist eine HTTP-Methode, die viele Male ohne unterschiedliche Ergebnisse aufgerufen werden kann. Es spielt keine Rolle, ob die Methode nur einmal oder zehnmal aufgerufen wird. Das Ergebnis sollte dasselbe sein. Dies gilt wiederum nur für das Ergebnis, nicht für die Ressource selbst. Dies kann weiterhin manipuliert werden (wie ein Update-Zeitstempel, sofern diese Informationen nicht in der (aktuellen) Ressourcendarstellung geteilt werden.

Betrachten Sie die folgenden Beispiele:

a = 4;

a ++;

Das erste Beispiel ist idempotent: Unabhängig davon, wie oft wir diese Anweisung ausführen, ist a immer 4. Das zweite Beispiel ist nicht idempotent. 10-maliges Ausführen führt zu einem anderen Ergebnis als 5-maliges Ausführen. Da beide Beispiele den Wert von a ändern, handelt es sich bei beiden um nicht sichere Methoden.

1
Bimal Das

Grundsätzlich ist REST ( wiki ):

  1. Client-Server-Architektur
  2. Staatenlosigkeit
  3. Cachefreundlichkeit
  4. Geschichtetes System
  5. Code auf Anfrage (optional)
  6. Einheitliche Schnittstelle

REST ist kein Protokoll, es sind Prinzipien. Unterschiedliche Methoden und Methoden - so genannte Best Practices.

0
M-A-X