Codes d’erreur et raisons
Ce document traite de l’API Drive. Si vous utilisez l’API Drive (classique), consultez le guide de référence pour les erreurs Drive (classique).
L'API Drive utilise des codes de réponse HTTP standard pour indiquer le succès ou l'échec d'une demande d'API.
Les plages de codes suivantes s'appliquent à tous les points de terminaison :
- 2xx – l'opération a réussi
- 4xx – l'opération a échoué en raison d'une erreur du client. Une nouvelle tentative entraînerait le même résultat
- 5xx – l'opération a échoué en raison d'une erreur temporaire de DoorDash, veuillez réessayer plus tard
- si le problème persiste, faites-le-nous savoir
Plus précisément, les codes suivants ont une signification commune à tous les points de terminaison :
- 200 – tout va bien
- 400 – la demande était syntaxiquement non valide et n'a pas pu être traitée
- la cause la plus probable est des paramètres manquants ou des paramètres avec des types de valeur incorrects
- 401 – erreur d'authentification
- la cause la plus probable est un jeton JWT (JSon Web Token) incorrect ou expiré, ce qui signifie que DoorDash n'a pas pu vérifier l'identité de l'appelant de façon sécurisée.
- 403 – erreur d'autorisation
- l'identité a été vérifiée de manière sécurisée, mais l'identité fournie ne permet pas l'opération ni l'accès aux données demandées
- 404 – la ressource n'existe pas
- la cause la plus probable est une mauvaise URL ou la recherche d'une livraison qui n'existe pas
- 409 – l'état du système ne permet pas de poursuivre l'opération
- la cause la plus probable est la création d'une nouvelle livraison avec un identifiant en double ou une tentative d'annulation d’une livraison qui n'est pas en cours
- 422 – erreur de validation logique
- la demande a été correctement formatée, mais l'opération ne peut pas être exécutée
- par exemple, demander une livraison en dehors de la zone de couverture
- 429 – trop de demandes
- trop de demandes envoyées dans un court laps de temps; veuillez attendre et réessayer
Format d'erreur standard
Lorsqu'une erreur est renvoyée, le format de réponse standard suivant est utilisé. Au besoin, certaines erreurs peuvent inclure des champs supplémentaires, mais les champs suivants sont inclus dans toutes les réponses aux erreurs.
{
"code": "validation_error",
"message": "Validation Failed"
}
code
est un énumérateur lisible par la machine dont les valeurs spécifiques sont propres à l'opération.
message
est une explication formulée en anglais qui et n'est incluse qu'à des fins de débogage.
Erreurs de validation
Les erreurs de validation (erreurs de la série 400 de la liste ci-dessus) ont des propriétés supplémentaires :
{
"code": "validation_error",
"message": "Validation Failed",
"field_errors": [
{
"field": "order_value",
"error": "Numeric value (100000000000) out of range of int (-2147483648 - 2147483647)"
}
]
}
field_errors
est un tableau de toutes les erreurs de validation rencontrées. Il faut noter que, selon l'entrée spécifique, il peut être impossible de retourner toutes les erreurs de validation.
Chaque erreur de validation est représentée par un objet ayant deux propriétés :
field
– le nom du champ, le nom du paramètre ou body
si aucun champ spécifique ne peut être attribué
error
– est une explication formulée en anglais qui et n'est incluse qu'à des fins de débogage.
Erreurs de logique
Les erreurs de logique (par exemple, la distance de livraison demandée est trop longue) suivent le format d'erreur standard. Les propriétés supplémentaires facultatives et les valeurs possibles de code
sont spécifiques à chaque opération et décrites à côté de celles-ci
Erreurs asynchrones
Certaines opérations peuvent échouer après que la réponse initiale a été retournée avec succès. Par exemple, une nouvelle livraison peut échouer après sa création s’il y a un problème de paiement.
Les erreurs asynchrones sont représentées comme des états de livraison. Pour les récupérer, le client doit demander les plus récentes informations sur la livraison et vérifier l’état de retour.