CreateOrUpdate Verantwortung in einer API

Question

Dies ist eine generische Design-Frage, aber wo sollte die Verantwortung in dieser Situation fallen? Soll der Anrufer prüfen, ob bereits ein Datensatz vorhanden ist, und dann Update aufrufen? Oder sollte es die Verantwortung des API sein, diese Entscheidung zu treffen?

Im ersten Szenario ist das Problem, dass der Anrufer mit der Geschäftslogik belastet ist, aber im zweiten Szenario, die Logik verschmutzt die API und erstellt hybrides Verhalten, Verletzung der Trennung der Interessen Prinzip.

Answer 1

Die Implementierung eines CreateOrUpdate-Endpunkts wird einige REST-Prinzipien durchbrechen, ist aber möglicherweise für den Anwendungsentwickler praktisch. Sie denken eher an einen Remote-Funktionsaufruf als an eine ressourcenorientierte API.

Betrachten Sie dies: Die API-URL identifiziert die Ressource.

Wenn die URL auf eine Sammlung zeigt (d. H./Customers /), dann ist die Aktion Erstellen (normalerweise der POST-Methode zugeordnet) sicherlich sinnvoll. Die Update-Funktion ist möglicherweise sinnvoll, wenn Sie die Aktualisierung auf mehrere Ressourcen gleichzeitig zulassen möchten. Der POST sollte den Code 201 und eine Kennung an eine neu erstellte Ressource zurückgeben (d. H./Kunden/1); oder wenn das Erstellen aufgrund einer bereits vorhandenen Ressource fehlgeschlagen ist, sollte Code 409 zurückgegeben werden. 400, wenn einige andere Einschränkungen wie Datenvalidierung nicht erfüllt sind.

Wenn die URL auf eine vorhandene Ressource zeigt (dh/customers/id/1), dann ist die Aktion Create nicht sinnvoll und sollte Code 400 ergeben. Das Update wird normalerweise der PUT-Methode (oder manchmal PATCH, if) zugeordnet partielle Ressourcenaktualisierung) und würde im Allgemeinen 200 zurückgeben, wenn das Update erfolgreich war, oder 4xx, falls nicht.

Wenn Sie einen/CreateOrUpdate-Endpunkt erstellen, der POST-Anforderungen annimmt, müssen Sie ein eigenes Protokoll erstellen, da dessen Verhalten und Rückgabewerte je nach Umständen unterschiedlich sind.

@Evert der PUT kann erstellen verwendet werden, aber nur, wenn Sie Client benötigen Sie den Endpunkt URI mit der Kennung dh

PUT /users/myusername 

Probleme damit zu formulieren sind:

1. muss der Client entdecken ein verfügbares,
2. Wenn ein natürlicher Bezeichner verwendet wird, kann es auch einen natürlichen Grund geben, es zu ändern, was je nach Implementierung problematisch sein kann

Der Hauptpunkt, den ich mache, ist zu vermeiden, REST-API-Endpunkte zu erstellen, die eine Aktion (Funktion) darstellen. Verwenden Sie stattdessen HTTP-Methoden, um entsprechende Aktionen für persistente Ressourcen auszuführen.