Was ist der richtige REST-Antwortcode für eine gültige Anfrage, aber leere Daten?

Question

Sie führen zum Beispiel eine GET-Anfrage für users/9 aber es gibt keinen Benutzer mit der ID #9. Welches ist der beste Antwortcode?

• 200 OK
• 202 Angenommen
• 204 Ohne Inhalt
• 400 Schlechte Anfrage
• 404 nicht gefunden

Answer 1

Wir haben es hier mit einer Spannung zwischen zwei Paradigmen zu tun.

In HTTP und REST identifiziert eine URL eine Ressource, die user/9 Ressource umfasst die 9 . HTTP sollte daher 404 - nicht gefunden zurückgeben. Dies ist die Definition von RESTful. Später können Sie PUT user/9 und beim nächsten Mal erhalten Sie dann die Daten. So wurden HTTP und REST konzipiert.

Und auf HTTP-Ebene, wenn Sie keine 404 wünschen, wäre eine bessere URL user?id=9 dann ist die user Teil gefunden werden, und die Funktion kann ihre eigene Verarbeitung durchführen und auf ihre eigene Weise die Meldung "nicht gefunden" zurückgeben.

Für die Bequemlichkeit der Spezifikation von APIs ist es jedoch einfach "viel schöner", die user/9 Format. Dies führt zu einem Dilemma: Diese Anfrage wurde über HTTP gestellt, und die (vermeintlich) korrekte HTTP-Antwort lautet 404; aber aus der Sicht der API-Konsumenten kann es sein, dass die Frameworks mit 404 nicht gut umgehen können und eine 200 + eine "not found"-Nutzlast wünschen (204 kann für viele Frameworks ebenfalls problematisch sein).

Das Aufsetzen einer API auf ein bereits definiertes Protokoll (HTTP) hat zu den Spannungen geführt. Es gibt kein Problem, wenn es als echte RESTful-API konzipiert ist (und die 404-Fehler korrekt behandelt werden, die dadurch entstehen würden).

Wenn Sie glauben, dass user/9 sollte 200 + "nicht gefunden" zurückgeben, dann verwenden Sie user als RPC-Endpunkt und dann die Kodierung der Parameter im Rest der URL. Ich würde sagen, dass dies ein schlechtes Design ist, das im Widerspruch zu einer RESTful-Spezifikation steht, und ich verstehe auch vollkommen, wie wir hierher gekommen sind.

Wenn Sie beide Seiten kontrollieren, sollten Sie das tun, was angesichts der Beschränkungen Ihres Servers und - was wahrscheinlicher ist - Ihrer clientseitigen Frameworks funktioniert.

(Denken Sie an die Folgen einer HEAD-Anfrage auf user/9 - Sie dürfen in der Antwort keinen Inhalt angeben. Ein 200 würde anzeigen, dass user/9 tatsächlich existiert, während 404 (korrekterweise) auf sein Fehlen hinweisen würde).

Answer 2

Warum nicht 410 verwenden? Es deutet darauf hin, dass die angeforderte Ressource nicht mehr existiert und dass der Client in Ihrem Fall nie wieder eine Anfrage für diese Ressource stellen wird. users/9 .

Weitere Informationen zu 410 finden Sie hier: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Answer 3

In diesem Szenario Ruby on Rails Antworten mit 404 Not Found .

Der Client hat eine Ressource angefordert, die nicht existiert. So, 404 Not Found angemessener ist.

---

bearbeiten

Ich sehe, dass in diesem Szenario viele Entwickler nicht gerne 404 not found .

Wenn Sie nicht möchten, dass 404 Ich denke, Sie können jeden dieser beiden Antwortcodes verwenden:

• 200 OK
• 204 Ohne Inhalt

Wenn Sie 200 OK : Antwortkörper sollte sein empty json : [] o {}

Wenn Sie 204 OK : Antwortkörper sollte leer sein.