Richtiger Weg, um eine Anfrage zu bearbeiten, die nicht wirklich etwas erstellt oder bekommt?

Question

Ich schreibe eine kleine App, die nur eine Sache macht: Nimmt einige vom Benutzer bereitgestellte Daten, führt eine Analyse durch und gibt ein "Tag" für diese Daten zurück. Ich denke, dass der Kunde entweder GET oder POST ihre Anfrage an /getTag, um eine Antwort zurück erhalten sollte.

Wenn der Client das tut, wird nichts auf dem Server gespeichert, so dass es sich komisch anfühlt, einen POST zu verwenden. Es gibt jedoch auch keinen einheitlichen URI für die Analyse, daher fühlt sich die Verwendung eines GET komisch an, da es abhängig davon, welche Daten bereitgestellt werden, unterschiedliche Dinge zurückgibt.

Wie können Sie diese Funktionalität am besten mit REST darstellen?

Answer 1

POST kann das Ausführen einer Aktion darstellen. Die Aktion hat keine als Datenbankaktion.

Was Sie wirklich erstellt haben, ist eine Remote-Prozedur. RPC ist normalerweise nur POST. Ich denke nicht, dass dies eine gute Lösung für REST ist, aber das muss Sie nicht davon abhalten, einfache URLs und JSON zu verwenden.

Answer 2

Der "beste Weg" ist, alles zu tun, was für Ihre Anwendung und ihre Bedürfnisse am besten geeignet ist. Nicht, dass zu wissen, hier sind ein paar Ideen:

1. GET das am besten geeignete Verb ist, da Sie nicht Erstellen oder auf dem Server zu speichern alles, nur etwas, das Abrufen, dass der Server zur Verfügung stellt.

2. Schreiben Sie nicht das Wort get in den URI, wie Sie vorgeschlagen haben. Verben wie diese werden bereits von HTTP bereitgestellt, verwenden Sie stattdessen einfach /tag und GET es.

3. Sie sollten einen gut verstandenen (oder "coolen") URI für diese Ressource verwenden und die Daten als Abfrageparameter übergeben. Ich würde mir keine Sorgen darüber machen, dass es sich seltsam anfühlt (siehe this question's Antworten, um herauszufinden, warum).

Um es zusammenzufassen, nur GET auf /tag?foo=bar&beef=dead, und du bist fertig.

Answer 3

Es scheint mir, als würde es wahrscheinlich einen Grund geben, warum Sie oder der Benutzer, der die Originaldaten generiert hat, das generierte Tag beibehalten möchten, oder nicht?

Wenn das eine Möglichkeit ist, dann würde ich es als POST /tags schreiben und den Ressourcen-URI /tags/:id als Location: header zurückgeben.

Wenn es mir wirklich egal war, den generierten Tag zu behalten, würde ich darüber nachdenken, was die "benutzergenerierten Daten" waren und wie viel Verarbeitung hinter den Kulissen passiert. Wenn das "Tag" anders ist als die Daten, die an das System übergeben werden, kann GET /tag für einen API-Consumer wirklich verwirrend sein.

Answer 4

Ich werde Sekunden Brians Antwort: Verwenden Sie eine GET. Wenn die gleichen Eingabeparameter die gleiche Ausgabe zurückgeben, und Sie wirklich nichts erstellen, ist es eine idempotente Aktion und somit perfekt geeignet für eine GET.

Answer 5

können Sie verwenden GET und POST entweder:

• GET /tag?data="..." -> 200, tag

  Die GET-Methode bedeutet, was Informationen (in Form einer Entität) abrufen durch den Anforderungs-URI identifiziert wird. Wenn sich der Anfrage-URI auf eines datenproduzierenden Prozesses bezieht, sind es die produzierten Daten, die als Entität in der Antwort zurückgegeben werden und nicht der Quelltext des -Prozesses, es sei denn, dass dieser Text die Ausgabe von ist verarbeiten.

• POST /tag {data: "..."} -> 200, tag

  Die von der POST-Methode durchgeführt, nicht in einer Ressource führen könnte , die durch einen URI identifiziert werden kann. In diesem Fall ist entweder 200 (OK) oder 204 (Kein Inhalt) der geeignete Antwortstatus, abhängig davon, ob oder nicht die Antwort eine Entität enthält, die das Ergebnis beschreibt.

gemäß dem HTTP-Standard/method definitions Abschnitt.

Ich würde GET verwenden, wenn ich Sie wäre (und POST nur, wenn Sie Dateien senden möchten).