Ich habe einen POST-Anforderungsendpunkt, an dem der Benutzer die Daten wiederholt veröffentlicht. Bevor ich die Daten in die Datenbank einfüge, überprüfe ich anhand der Benutzeranfrage, ob der Datensatz bereits existiert. - Wenn der Datensatz bereits existiert, gebe ich 200 OK mit dem Antworttext zurück, der die Tabelle_ID und den Status enthält - Wenn der Datensatz nicht existiert, erstelle ich einen neuen Datensatz und gebe 200 OK mit dem Antworttext zurück, der table_id und status enthält
In beiden Fällen erhält der Benutzer den Status 200. Als Benutzer kann es verwirrend sein, da man nicht unterscheiden kann, ob es sich um einen neuen Datensatz oder um einen bestehenden Datensatz handelt.
Ich dachte, ich würde 304 mit der Antwortstelle zurückgeben und den Verbraucher informieren, dass diese Anfrage "Nicht geändert" ist, auf diese Weise würden die Verbraucher eine Entscheidung treffen.
Ist es eine gute Übung oder gibt es einen alternativen Ansatz in RESTful-Prinzipalen?
304 soll nur für eine Bedingte GET -Antwort verwendet werden, um anzuzeigen, dass sich der angeforderte Inhalt seit der letzten Anfrage des Clients nicht geändert hat. Es ist nicht geeignet für eine POST Antwort.
Verwenden Sie für eine POST -Antwort 201 , wenn ein neuer Datensatz erstellt wird, andernfalls verwenden Sie stattdessen 200 oder möglicherweise 409 .
Im Folgenden finden Sie einige hilfreiche Tipps zum Entwerfen von REST-APIs:
Verwendung von HTTP 304 als Antwort auf POST
HTTP-Antwortcode für POST, wenn die Ressource bereits vorhanden ist
304 Not Modified wird verwendet, wenn HTTP-Cache-Header im Spiel sind. Dies trifft also nicht auf Ihren Fall zu.
Ich würde 422 Unprocessable Entity für Validierungsfehler verwenden, wenn die Anfrage wohlgeformt ist, aber es semantische Fehler gibt.
Und wenn der Datensatz vorher nicht existierte, sollten Sie mit 201 Created (statt 200 OK ) antworten, das ist die Standardantwort auf eine erfolgreiche Ressourcenerstellung (nach einer POST-Erstellungsanforderung).