Handle CRUD in REST API Wenn Read benötigt ein POST

Question

Ich versuche, eine API zu erstellen, die REST-Best-Practices folgt, intuitiv ist und Übereinstimmungen mit den Mustern, die Entwickler von anderen (gut gestalteten) APIs sehen. Ich glaube, dass ich die verschiedene Mapping der HTTP-Verben zu den typischen Ressourcen zu verstehen, die mit den Antworten in diesen beiden Fragen in Zeile ist:

Which HTTP methods match up to which CRUD methods?

Understanding REST: Verbs, error codes, and authentication

Wo ich Probleme habe, ist, dass Aufgrund der Art unseres Geschäfts und der zum Abrufen von Daten erforderlichen Daten, die normalerweise ein GET wären, müssen wir einen POST verwenden. Dies liegt sowohl an der Größe der Anfrage als auch daran, was wir weitergeben, um die Suche durchzuführen.

When do you use POST and when do you use GET?

Also, es gibt ein paar Ansätze ich auf denken, wie CRUD am besten handhaben, und ich habe die Liebe einige Vorschläge:

1. Verwenden Abfrageparameter in der POST für CREATE differenzier vs READ, andere Verben als normal. Ich mag diese Idee nicht.
2. Haben Sie einen separaten Endpunkt für jede Aktion, z./baseUrl/lookup,/baseUrl/create. Folgt nicht dem richtigen Muster der Verwendung von Substantiven anstelle von Verben.

EDIT: Im Interesse der Klarheit, das erfundene Beispiel in meinen Kommentaren eines Bild Lookup-Service, wo ein Anrufer suchen, wenn ein Bild bereits in der Datenbank vorhanden ist, um ein neues Bild hinzufügen, aktualisieren Sie das Bild (zB Metadaten hinzufügen) oder löschen Sie das Bild.

Erstellen:Was sollen wir hier tun? POST/image/Erstellen und aktualisieren Sie den Lese-Endpunkt nach/image/search?

lesen: POST/Bild {imagedata = someBase64EncodedImage}

Update: PUT/image/{imageId}

Löschen: DELETE/image/{imageId}

Answer 1

Ich denke, dass es ein Missverständnis über die Verwendung von POST zum Abrufen von Ressourcen gibt. Von einem hohen Standpunkt aus, geben Sie ein Problem wie folgt an:

Ich muss eine Liste der Entitäten vom Server abrufen, die eine Vielzahl von Parametern entsprechen. Wie kann ich das erreichen?

So ist die tempation, ein POST als ein Mittel für das Anfordern eines READ zu sehen, stark. Und gleichzeitig ist es irreführend. Überall hören Sie REST-Evangelisten schwören, dass ein READ über eine GET implementiert werden sollte und Tunneling-Operationen mit POST ist ein REST Antipattern.

Die Lösung des Problems ist sehr einfach und es geht darum, unseren Ansatz zu ändern. Es ist nicht POST ing für READING.Es geht darum, ein Anfrageticket an den Server zu senden und auf eine Antwort zurück zu warten. Und in der Tat ist es definitiv, was wir tun, mit einem POST. A POST, erstellt eine Subresource, Zeitraum (ja, es kann auch für die Aktualisierung verwendet werden, aber ich will nicht in Details verloren gehen).

Wenn Sie also einen Server nach einer komplexen Ressource abfragen möchten, legen Sie einfach ein Ticket ab und warten auf eine Antwort. Lassen Sie uns einen Anwendungsfall prüfen:

Sie haben eine car durch die folgende URI identifizierte Ressource

http://authority/api/cars/{id}

und, sagen wir, wollen Sie den Server in einer sehr komplexen Weise abgefragt werden, indem ein POST Ausgabe.

Welchen Endpunkt verwenden Sie? Auf jeden Fall kann man nicht gehen mit

POSThttp://authority/api/cars

, denn wenn Sie das tun, was Sie erwarten nichts anderes als ein Auto Schöpfung zu erhalten ist, ist es nicht? Die Lösung ist wiederum sehr einfach. Sie versuchen, ein Abfrageticket an den Server zu senden, also sollten Sie diese Ressource ablehnen. Sie könnten mehr kreativ sein, aber vielleicht könnte dies

POSThttp://authority/api/tickets/cars

POST ing eine Abfrage Ticket zu diesem Endpunkt arbeiten können Sie erwarten eine Antwort zurück mit einem location Header haben, um eine Liste der Fahrzeuge beziehen (a Autos Ressource), die Ihrer Anfrage entsprechen (Statuscode 201 = Creted oder 202 = akzeptiert, das Ergebnis ist so schnell wie möglich verfügbar). Wenn die Berechnung schnell genug ist, ist es keine Todsünde, das Ergebnis in die HTTP-Antwort (persönliche Meinung) aufzunehmen.

Für eine umfassendere Dissertation finden Sie in diesem brillanten Artikel: How to GET a Cup of Coffee.