HTTP-Statuscode in Microservices

[H4110]

Das ist ebenfalls schlicht falsch. Die Konvention ist, dass eine legitime Anfrage keinesfalls als nicht legitim (4xx) quittiert werden darf.

Das ist jetzt echt eine vertrackte Situation. Ist zufällig ein auf Existentialismus spezialisierter Philosoph anwesend? 🤪

 

[Evil E-Lex]

Die Konvention ist, dass eine legitime Anfrage keinesfalls als nicht legitim (4xx) quittiert werden darf.

Ein 404 würde ich nicht als "nicht legitim" ansehen, da der Fehler temporärer Art sein kann.

 

[kali-hi]

auf Existentialismus spezialisierter Philosoph anwesend?

Ein Philosoph hat doch von Technik oder Semantik keine Ahnung...

In der https://de.wikipedia.org/wiki/Prädikatenlogik_erster_Stufe kann man sowohl ∅ als auch {∅} als auch ∄ schreiben (empty, empty set und not exists), je nach dem, was der Dozent gerne hätte.

 

[BeBur]

@kali-hi Will jetzt hier nicht vom Thema wegführen, aber ∅ und {∅} sind zwei verschiedene Dinge (∄ ist noch was kategorisch anderes). ∅ ist die (einzige) Menge, die keine Elemente hat, auch bekannt als leere Menge und {∅} ist eine einelementige Menge welche die leere Menge enthält.
Generell scheint mir das den problematischen Punkt hier ganz gut zu treffen.

 

[simpsonsfan]

Von dem was ich hier (und auf der verlinkten StakOverflow-Diskussion) lese, gibt es doch eigentlich zwei prinzipielle Möglichkeiten:

• Man betrachtet die Ressource als nicht vorhanden, ein GET darauf gibt 404. Der Client sollte nicht versuchen, ein GET auf die Ressource zu senden, bevor er nicht aus anderer Quelle weiß, dass die Ressource existiert.
• Die Ressource ist vorhanden, aber leer. Man gibt wahlweise "null", "{}", "{null}" o.ä. zurück und Returncode 200. Der Client kann wie er lustig ist ein GET auf die Ressource starten, am Server ist sie ja für alle existenten User immer vorhanden (aber halt leer.)

Wäre mal mein Ansatz.

 

[kali-hi]

{∅} ist eine einelementige Menge welche die leere Menge enthält

Ja, sorry, ich meinte nicht {∅}, sondern {}. Also: ∅, {} oder Nil / ∄ / not exists.

Wikipedia kennt aber noch mehr: https://de.wikipedia.org/wiki/Liste_mathematischer_Symbole#Mengenlehre

Wie dem auch sei, ich wollte damit zeigen, das es fast keine semantischen Unterschiede zwischen den Schreibweisen mehr gibt, und somit zu einer Interpretationssache wird. Und bei den HTTP REST status return values verhält sich dies ähnlich.

• 404 bedeutet einfach nur: Das Element (die Ressource) ist nicht da! Das bedeutet nicht, dort sollte aber etwas sein, dort könnte in Zukunft etwas sein, oder dort war in der Vergangenheit etwas.
• 204 bedeutet (KI-Antwort) "No Content", also dass der Server die Client-Anfrage erfolgreich bearbeitet hat, aber keinen Inhalt in der Antwort zurücksendet. Dies ist typisch für Aktionen wie das Löschen von Ressourcen oder das Aktualisieren von Daten, bei denen keine neuen Informationen zurückgegeben werden müssen, um den Erfolg der Anfrage anzuzeigen. Der Client sollte die Ansicht der Seite nicht ändern, sondern beibehalten.

204 wäre für mich nahe liegender, weil auch ein Erfolg der Anfrage (Validität) signalisiert wird.

 

[Piktogramm]

Wenn ich an Programmiersprachen denke, dann sollte eine Funktion, die etwas vom Typ T zurückliefert laut Interface auch wirklich ein gültiges T zurückliefert oder ansonsten etwas vom Typ optional<T> zurückliefern stattdessen.

Meine Intuition ist daher, das man nicht 200 + leere config zurückgeben sollte (default config, falls das sinn ergibt wäre dieser Logik folgend aber natürlich okay).

Du zitierst einen Post, der eben die Problematik einer leeren Rückgabe sogar beleuchtet und daher damit schließt, dass ein sinnvolles "hier ist leer" besser wäre.

Das ist aber im Falle von REST APIs schlicht falsch. Die Konvention ist, dass das Abrufen einer nicht vorhandenen Resource mit einem 404 quittiert werden muss.

[citation needed]

Zudem REST als Konzept meines Wissens nach nirgend wirklich standardisiert wurde. Allenfalls gibt es da div. Quellen die ihre Konventionen aufgeschrieben. Daher ist "die Konvention" schlicht abenteuerlich.
Die HTTP Fehlercodes sind kein Teil von REST sondern HTTP und die aktuelle Norm dazu ist RFC9110.

Und da wären wir dann wieder an dem Punkt. Nach Norm ist es richtig nicht vorhandene Ressourcen mit einem 404 zu beantworten. Es ist nur kein gutes Design einer API, wenn valide Endpunkte Fehler werfen und/oder Rückgaben die sich von anderweitigen Fehlern nicht unterscheiden lassen.

 

[SheepShaver]

Nö. Das ist ein erwartbarer Fehlerfall, genau wie 401 oder 403.
Der Client kann schlicht nicht wissen, ob eine Ressource überhaupt existiert oder ob er Zugriff darauf hat. Deshalb muss er diese Antworten verarbeiten können.
Nach HTTP-Spec (RFC 9110) ist die Semantik eindeutig: Wenn eine Ressource nicht existiert, gehört ein 404 zurück. Wird der Zugriff verweigert, ist es ein 403. Fehlt eine gültige Authentifizierung, ist es ein 401.
Ein 200 mit leerem Body oder einer leeren Default-Config vermischt Semantik, erschwert Caching, Logging und Fehlerbehandlung und ist letztlich schlechtes API-Design. Wenn eine Collection vorhanden ist, aber gerade keine Elemente enthält, dann ist ein 200 mit leerer Liste sinnvoll. Wenn ein Item nicht existiert, ist es ein 404. Für erfolgreiche Operationen ohne Rückgabekörper ist ein 204 No Content vorgesehen.
Wer bei "nicht vorhanden" ein 200 liefert, bricht die HTTP-Semantik und macht dem Client das Leben unnötig schwer.

Kurzes Beispiel Upload einer Datei über eine REST API:
Beim Preflight-Check vor einem Upload fragt der Client die gewünschte Datei an, zum Beispiel per HEAD /files/report.pdf. Bekommt er ein 200 OK, weiß er, dass die Datei bereits existiert und ein Upload sie überschreiben würde. Kommt dagegen ein 404 Not Found, bedeutet das eindeutig, dass die Ressource noch nicht existiert und der Upload eine neue Datei anlegt. Ein 403 Forbidden oder 401 Unauthorized signalisiert, dass der Zugriff nicht erlaubt ist. Genau hier zeigt sich, warum 404 sinnvoll ist: Der Client kann klar unterscheiden, ob er eine bestehende Version überschreibt oder eine neue anlegt, anstatt mit einem leeren 200-Response im Unklaren zu bleiben.

Ansonsten: das Thema wurde in der Vergangenheit schon hinreichend und abschliessend ausdiskutiert:
https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/#h2-3f9e93268ff40

 

[kali-hi]

API-Design

Das sehe ich prinzipiell auch so, letztendlich ist es eine Designentscheidung/ Ermessenssache/ Team-Geblubber... Das hab ich aber auch schon in #18 angedeutet.

Ansonsten: das Thema wurde ... ausdiskutiert

auch schon in #18 angedeutet... letztendlich ist es ein Implementierungsdetail des Backends, um das sich der Client nicht kümmern muss... Der Client muss eigentlich nur "die grundsätzliche Flugrichtung" kennen, wohin die Reise gehen soll... also eher nur das Was, nicht das Wie (im übertragenen Sinne).

 

[foofoobar]

Kurzes Beispiel Upload einer Datei über eine REST API:
Beim Preflight-Check vor einem Upload fragt der Client die gewünschte Datei an, zum Beispiel per HEAD /files/report.pdf. Bekommt er ein 200 OK, weiß er, dass die Datei bereits existiert und ein Upload sie überschreiben würde. Kommt dagegen ein 404 Not Found, bedeutet das eindeutig, dass die Ressource noch nicht existiert und der Upload eine neue Datei anlegt. Ein 403 Forbidden oder 401 Unauthorized signalisiert, dass der Zugriff nicht erlaubt ist. Genau hier zeigt sich, warum 404 sinnvoll ist: Der Client kann klar unterscheiden, ob er eine bestehende Version überschreibt oder eine neue anlegt, anstatt mit einem leeren 200-Response im Unklaren zu bleiben.

Da ist eine Race Condition drin.

 

[H4110]

Jo. Wenn man eine neue Datei hochlädt, sollte man POSTen, und wenn die wider erwarten bereits existiert, sollte der Server 409 liefern. Zum Überschreiben PUT mit If-Match oder If-Unmodified-Since (ETag bzw. Timestamp kann man sich vorher mit HEAD holen), und falls die Datei zwischenzeitlich geändert wurde, sollte der Server 412 liefern.

 

[SheepShaver]

Das Beispiele diente dazu, klarzustellen, dass ein 204 oder ein 200 mit einem Default-Payload eine schlechte Idee ist. Ein Ausflug in die Unterschiede von POST und PUT ist hier nicht zielführend.