From ca4f0d2bd213428b3b2973aba492e94c5796a4bd Mon Sep 17 00:00:00 2001 From: PublicServiceGuy <alexander.hoose@fitko.de> Date: Thu, 26 Mar 2020 22:43:00 +0100 Subject: [PATCH] Status- und Fehler erstellt --- docs/5_Status-_und_Fehlercodes.md | 42 ++++++++++++++++++++++++++----- docs/README.md | 4 ++- 2 files changed, 39 insertions(+), 7 deletions(-) diff --git a/docs/5_Status-_und_Fehlercodes.md b/docs/5_Status-_und_Fehlercodes.md index f38a3127..ae4caa03 100644 --- a/docs/5_Status-_und_Fehlercodes.md +++ b/docs/5_Status-_und_Fehlercodes.md @@ -1,15 +1,45 @@ # Status- und Fehlercodes -The beginning of an awesome article... +Die XFall APIs liefert in allen Responses die entsprechenden HTTP Response Codes. In der aktuell vorliegenden API Version werden nur HTTP Response Codes verwendet, die im ([RFC 7231](https://tools.ietf.org/html/rfc7231)) beschrieben sind. -### Rückmeldungen zu clientseitig verursachten Fehlern +API Clients sollten aber gemäß RFC 7231 so implementiert, dass auch unbekannte Response Status Codes (Neue verwendete Standardcodes oder proprietäre Erweiterungen) gemäß ihrer Statusklasse interpretiert werden können: +> "HTTP status codes are extensible. HTTP clients are not required to + understand the meaning of all registered status codes, though such + understanding is obviously desirable. However, a client MUST + understand the class of any status code, as indicated by the first + digit, and treat an unrecognized status code as being equivalent to + the x00 status code of that class, with the exception that a + recipient MUST NOT cache a response with an unrecognized status code." -Zu einer Fehlermeldung, die durch den API-Client verursacht wurde (Kategorie 4XX), liefert die API über die Angabe Erroreine detailierte Rückmeldung zu einer nicht erfolgreichen Operation. Sie enthält folgende Angaben: +### Übersicht der verwendeten Response Codes und ihre Bedeutung - code: integer - Fehlercode +Code | Text | Bedeutung +---------|----------|--------- + 200 | OK | Der Request war erfolgreich. + 201 | Created | Eine Ressource wurde erfolgreich angelegt. + 202 | Accepted | Daten wurden wurden erfolgreich übertragen und angenommen. + 400 | Bad Request | Der Request war nicht korrekt aufgebaut. + 401 | Unauthorized | Der Request lieferte keine oder eine ungültige Authentifikation. + 404 | Not Found | Die Ressource kann nicht unter dem angegeben Pfad gefunden werden oder temporär nicht verfügbar. + 406 | Not Acceptable | Request Body entspricht nicht dem vorgebenen Schema. + 410 | Gone | Die Ressource ist unter dem Pfad permanent nicht mehr verfügbar. (bspw. weil die Ressource gelöscht wurde in dieser Repräsentation nicht mehr verfügbar ist) + 413 | Request Entity Too Large | Der übertragene Datensatz ist zu groß. + 415 | Unsupported Media Type | Der Datentyp wird nicht unterstützt. + 500 | Internal Server Error | Es besteht ein Fehler auf Seite des API Providers. - msg: string - Fehlermeldung +### Detailangaben zu clientseitig verursachten Fehlern - ref: string - Referenz auf fehlerhafte Stelle +Für Fehlermeldungen, die durch den API-Client verursacht wurden (HTTP Statusklasse 4XX), liefert die API im Response Body über eine Error Mitteilung eine detailierte Rückmeldung zu einer nicht erfolgreichen Operation. +Eine Error Mitteilung enthält folgende Angaben: + + code: Standardisierter Fehlercode + + msg: Textuelle Fehlermeldung + + ref: Referenz auf fehlerhafte Stelle + +### Liste der Fehlercodes + +**... Noch in der Erstellung ...** \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index dbd64fee..cbd8c65c 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,9 +1,11 @@ -# Überblick über die XFall REST +# Überblick über das XFall-Gateway Die übergreifende Zielstellung von XFall besteht darin, Anträge und Berichte, die aus den vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportal oder Berichtssysteme) erstellt werden, in die elektronische Verfahrensbearbeitung der Verwaltung zu übergeben. Um diese übergreifende Zielstellung zur erfüllen, werden dem Sender eines Antrags (`Sender`) und Empfänger eines Antrags (`Subscriber`) dedizierte APIs bereitgestelt, um Anträge bzw. Berichte beim XFall API-Gateway abzugeben bzw. abzuholen. + + ### Welches Problem löst das XFall-Gateway bzw. die dahinliegende Integrationsinfrastruktur? ... -- GitLab