For the German version, please scroll down to “Dokumentation (Deutsch)”
Enterprise API use worldwide-adopted semantics of the HTTP Response Codes. More about that can be found here.
Transient error are the temporary ones. The perfect example of
transient error is the HTTP 503 Service Unavailable.
429 Too Many Requests
Each subscription has only some certain amount of requests per minute allowed. In case of this threshold is exceeded the HTTP 429 response code is returned.
500 Internal Service Error
This error may happen because of the unhandled error in the server code. No required retry from the client side is needed. If observed this situation will be handled by the DKV IT. Client should try to use the API later.
502 Bad Gateway
This error may happen because the BE temporarily can not be accessed on the network level. It’s recommended to apply exponential backoff retry in this case.
503 Service Unavailable
This error may happen because the BE is temporarily unavailable. It’s recommended to apply exponential backoff retry in this case.
504 Gateway Timeout
This error may happen because the BE was not able to respond within predefined timeout for the API. It’s recommended to apply exponential backoff retry in this case.
408 Request Timeout
This error shows that the API did not respond in the same speed as the client expected. API Consumers should not frequently see this error.
Non-transient errors are permantent ones. They require changes on the
client-side. The perfect examples of non-transient error are the
HTTP 400 Bad Request and
HTTP 401 Unathorized.
400 Bad Request
This error happens when the client’s request does not fit to the schema. It does not make sense to retry sending the same request when the response is HTTP 400. Client has to take care of fixing the request
401 Unauthorized
This error happens when the client’s request does not have valid authentication or authorization. It does not make sense to retry sending the same request when the response is HTTP 401.
Hier finden Sie die deutsche Dokumentation.
Die Enterprise API verwendet weltweit anerkannte Semantiken der HTTP-Antwortcodes. Weitere Informationen dazu finden Sie here.
Temporäre Fehler sind vorübergehende Fehler. Ein perfektes Beispiel für einen temporären Fehler ist der HTTP 503 Service Unavailable.
429 Too Many Requests
Jede Abonnement (subscription) hat nur eine bestimmte Anzahl von Anfragen pro Minute, die erlaubt sind. Wenn dieser Schwellenwert überschritten wird, wird der HTTP 429-Antwortcode Zu viele Anfragen zurückgegeben.
500 Internal Service Error
Dieser Fehler kann auftreten, wenn ein unbehandelter Fehler auf der Server-Seite aufgetreten ist. Von der Client-Seite ist kein erforderliches erneutes Senden nötig.
DKV IT wird diese Situation bemerken und schnell handeln. Der Client sollte versuchen, die API Anfrage später zu senden.
502 Bad Gateway
Dieser Fehler kann auftreten, wenn das Backend vorübergehend auf Netzwerkebene nicht erreichbar ist. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
503 Service Unavailable
Dieser Fehler kann auftreten, wenn das Backend vorübergehend nicht verfügbar ist. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
504 Gateway Timeout
Dieser Fehler kann auftreten, wenn das Backend nicht in der vorgegebenen Zeit eine API-Antwort geschickt hat. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
408 Request Timeout
Dieser Fehler zeigt, dass der Client die API-Anfrage beendet hat, bevor die API reagiert hat.
Diese fehler erfordern Änderungen auf der Client-Seite. Perfekte
Beispiele für nicht-temporäre Fehler sind
HTTP 400 Bad Request und
HTTP 401 Unathorized.
400 Bad Request
Dieser Fehler tritt auf, wenn die Anfrage des Clients nicht der Anfrage-Schema entspricht. Es macht wenig Sinn, dieselbe Anfrage erneut zu senden, wenn die Antwort HTTP 400 zurückkommt.
Der Client soll sich um die Fehlerbehebung kümmern.
401 Unauthorized
Dieser Fehler tritt auf, wenn die Anfrage des Clients keine gültige Authentifizierung oder Autorisierung hat.
Es macht wenig Sinn, dieselbe Anfrage erneut zu senden, wenn die Antwort HTTP 401 zurückkommt.