Landkarte der Statuscodes

Worum es geht

Jede Antwort hat einen HTTP-Statuscode, eine dreistellige Zahl. Die erste Ziffer sagt, wer handeln muss:

• 2xx: Es hat geklappt.
• 4xx: Die Anfrage passt nicht. Der Client muss etwas ändern, bevor ein neuer Versuch Sinn hat.
• 5xx: Im Server ist etwas schiefgegangen. Der Client kann an der Anfrage nichts verbessern.

Wo die Codes entstehen

Eine Anfrage läuft durch mehrere Stationen. Jede Station hat ihre eigenen Codes:

Wann Rolle und wann Sichtbarkeit zuerst geprüft wird, steht unter 401, 403 oder 404?.

Die Matrix

Was nach jedem Code gespeichert ist und wie du wiederholst, steht unter Darf der Client wiederholen?.

200: erfolgreich

Jede erfolgreiche Anfrage liefert 200, auch ein create und ein delete. Codes wie 201 oder 204 gibt es nicht. Ein Löschen antwortet mit leerem Körper, alles andere mit data. Siehe Das Antwortformat.

Einen Sonderfall gibt es: Im Modus LENIENT kann ein create gelingen und nur das Zurücklesen scheitern. Dann kommt 200 mit einem Körper in Fehlerform, dem messageKey CDMS_CREATE_SUCCEEDED_READ_FAILED und der id des neuen Objekts. Das Objekt ist gespeichert, lege es nicht noch einmal an. Siehe Anlegen und Zurücklesen.

400: die Anfrage ist fehlerhaft

400 heißt: So, wie die Anfrage ist, kann CDMS sie nicht ausführen. Der messageKey sagt, was nicht passt, oft mit dem Pfad oder Feld dahinter.

401 und 403: wer du bist und was du darfst

401 kommt nur von der Filterkette: Das Token ist abgelaufen, kaputt oder falsch signiert. Die Antwort hat keinen Körper, aber den Header WWW-Authenticate: Bearer error="invalid_token". Erneuere das Token und wiederhole die Anfrage einmal.

403 heißt: Diese Anfrage ist für dich nicht erlaubt. Es gibt drei Quellen:

Siehe Zugriff ohne Token, Modellrollen und Strict Mode.

404: nicht gefunden

404 mit messageKey heißt: Das Objekt gibt es nicht, oder du darfst es nicht sehen. CDMS unterscheidet das absichtlich nicht. Typische Schlüssel sind not-found, not-found|<Dto>|<id>, missing-object|… für ein fehlendes Kind in einer Beziehung und no-data-exists|use-create bei einem Singleton, das es noch nicht gibt.

404 ohne messageKey heißt: Den Pfad gibt es nicht. Meist ist der Modellpfad falsch geschrieben, oder das Modell hat diesen Endpunkt nicht. Siehe Warum Unsichtbares 404 liefert und Welche Endpunkte ein Modell hat.

409: Konflikt

409 heißt: Die Änderung passt nicht zu den Daten, die schon gespeichert sind. Nichts ist gespeichert. Es gibt drei Fälle:

Den gleichzeitigen Schreibkonflikt gibt es nur bei Datei-Modellen, bei allen anderen Modellen gewinnt die letzte Änderung ohne Fehler. Siehe Gleichzeitige Änderungen.

422: der Inhalt verletzt Regeln

422 heißt: Die Anfrage ist richtig gebaut, aber ihr Inhalt verletzt eine Regel.

500: Fehler im Server

500 heißt: Im Server ist etwas passiert, das der Client nicht beheben kann. Es gibt zwei Arten:

• Unerwarteter Fehler. Der messageKey ist details see logfiles, layer ist undefined. Die Ursache steht im Server-Log.
• Fehler in der Einrichtung. Das Projekt ist falsch eingerichtet, der messageKey nennt es. Beispiele: unresolvable-mandatory-filter|… bei einem Filter auf ein Feld, das es nicht gibt, und CDMS_TENANT_DATASOURCE_NOT_FOUND, wenn die Datenbank des Mandanten fehlt.

Auch eine unerwartete Ausnahme in einem Hook endet mit 500. Eine Wiederholung hilft in keinem dieser Fälle. Gib Status, messageKey und Zeitpunkt an das Team weiter.

503: die Datenbank ist nicht erreichbar

503 heißt: Die Datenbank kann die Anfrage gerade nicht bedienen. Nichts ist gespeichert, die Transaktion ist zurückgerollt. Das ist eine Störung, kein Fehler in deinen Daten: Eine Wiederholung nach einer Pause kann gelingen.

Lehnt die Datenbank eine Änderung dagegen wegen der vorhandenen Daten ab, kommt 409, und eine unveränderte Wiederholung scheitert genauso. Siehe oben.

Ablehnungen beim Hochladen

Beim Hochladen von Dateien lehnt CDMS eine Anfrage mit 400 ab, wenn zwei Teile denselben Dateinamen haben (duplicate-filenames|<name>), ein Teil keinen Dateinamen hat (missing-filename) oder sich der Multipart-Körper nicht lesen lässt (malformed-multipart). Ist eine Datei, der ganze Request oder die Zahl der Teile zu groß, kommt 413, und der messageKey nennt die Grenze, etwa file-too-large|26214400 (Bytes). Prüfe Namen und Größe schon im Client. Siehe Hochladen und Größengrenzen.

Fallen

Wie es weitergeht

• Wie eine Fehlerantwort aufgebaut ist: Das Fehlerformat
• Die drei häufig verwechselten Codes: 401, 403 oder 404?
• Was nach einem Fehler gespeichert ist: Ein Request, eine Transaktion