Codes d'erreur de l'API Métadonnées

Comme indiqué dans la section Gestion des erreurs, l'API des métadonnées VPC utilise les codes de réponse standard HTTP pour indiquer le résultat d'une demande. Par exemple, une réponse 4xx-series indique un échec que le client doit résoudre. Une réponse 5xx indique un incident de service.

En outre, toutes les réponses 4xx et 5xx incluent un objet de réponse d'erreur JSON qui fournit des informations supplémentaires sur le problème. Ces informations comprennent une propriété trace dont la valeur peut être demandée par l'assistance IBM lors du dépannage de la panne, et une propriété errors array qui contient une ou plusieurs erreurs spécifiques liées au problème. Chaque élément du tableau errors utilise le schéma JSON suivant :

code - Chaîne de code d'erreur, telle que invalid_value
message-Chaîne de texte qui décrit le message d'erreur, par exemple, "La valeur fournie pour la zone expires_in doit être comprise entre 5 et 3600."
more_info - Si présent, lien vers la documentation relative à cette erreur
target- Pour les erreurs qui renvoient une propriété target dans la réponse, examinez les sous-propriétés pour trouver des indices :
- name de la zone, du paramètre de requête ou de l'en-tête problématique
- type de l'entrée où le problème a été détecté, par exemple une zone
- value (si présent) la valeur problématique dans la zone, le paramètre de requête ou l'en-tête

Exemple d'objet de réponse d'erreur 400 JSON :

{
  "errors": [
    {
      "code": "invalid_value",
      "message": "The `expires_in` field must not exceed `3600`.",
      "more_info": "https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-service",
      "target": {
        "name": "expires_in",
        "type": "field",
        "value": "7200"
      }
    }
  ],
  "status_code": 400,
  "trace": "e37872f6-f9a4-4084-a1a8-e56a1c8c8d3d"
}

Les codes d'erreur peuvent être ajoutés, supprimés ou modifiés dans les versions ultérieures, les mises à jour étant annoncées dans le journal des modifications de l'API des métadonnées VPC. Si vous utilisez des codes d'erreur à l'aide d'un programme, nous vous recommandons de les coder de manière défensive. Tout code qui recherche des codes d'erreur spécifiques doit toujours avoir une clause "default" ou "catch-all". Il peut donc gérer le cas où le code d'erreur renvoyé ne correspond à aucun des codes attendus.

`invalid_request`

Utilisé lorsque la demande ne peut pas être analysée, par exemple, lorsque la demande JSON est mal formée ou que le corps de la demande est trop volumineux.

Le code d'erreur invalid_request peut accompagner un code de statut HTTP 400.

Exemple de message : le corps de la demande était mal formé.

`invalid_value`

Utilisé pour les valeurs non valides pour les en-têtes, les paramètres de requête, les paramètres de chemin ou les propriétés (identifiés par target). Inclut des valeurs entières qui sont hors plage, des valeurs de chaîne qui comportent des caractères non valides, des énumérations hors de l'ensemble indiqué, etc.

Le code d'erreur invalid_value peut accompagner les codes de statut HTTP suivants :

404 pour les paramètres de chemin
400 pour tous les autres cas

Exemple de message : la valeur fournie pour la zone expires_in doit être comprise entre 5 et 3600.

`missing_field`

Utilisé dans le cas où un en-tête, un paramètre de requête ou une propriété requis ne sont pas fournis.

Le code d'erreur missing_field peut accompagner un code de statut HTTP 400.

Exemple de message : un ID de profil sécurisé n'a pas été transmis dans le corps de la demande.

`missing_value`

Utilisé pour les en-têtes obligatoires, les paramètres de requête ou les propriétés de corps manquants (identifiés par target).

Le code d'erreur missing_value peut accompagner un code de statut HTTP 400.

Exemple de message : une valeur telle que ibm doit être fournie dans l'en-tête Metadata-Flavor.

`not_found`

Utilisé pour les en-têtes, les paramètres de requête, les paramètres de chemin ou les propriétés du corps (identifiés par target) qui sont syntaxiquement valides, mais qui font référence à une ressource qui n'existe pas.

Le code d'erreur not_found peut accompagner les codes de statut HTTP suivants :

404 pour les paramètres de chemin
400 pour tous les autres cas

Exemple de message : groupe de placement introuvable.

`profile_not_linked`

Utilisé lorsqu'un profil sécurisé n'est pas lié à une instance de serveur virtuel. Ce code d'erreur est renvoyé uniquement pour la méthode POST /instance_identity/v1/iam_token.

Le code d'erreur profile_not_linked peut accompagner un code de statut HTTP 400.

Exemple de message : l'instance de serveur virtuel n'est pas liée au profil de confiance spécifié.

`service_error`

Utilisé lorsque le client rencontre un problème côté service.

Le code d'erreur service_error peut accompagner un code de statut HTTP 500.

Exemple de message : une erreur interne s'est produite.

`unauthenticated`

Utilisé lorsqu'un jeton Bearer est fourni dans l'en-tête Authorization et que le jeton est arrivé à expiration, syntaxiquement incorrect ou syntaxiquement correct, mais pas valide.

Le code d'erreur unauthenticated peut accompagner un code de statut HTTP 401.

Exemple de message : le jeton fourni n'est pas valide ou est arrivé à expiration.

`unauthorized`

Utilisé pour les en-têtes, les paramètres, les chemins d'accès ou les propriétés (identifiés par target) qui sont syntaxiquement valides mais qui font référence à une ressource que vous n'êtes pas autorisé à utiliser de la manière demandée.

Le code d'erreur unauthorized peut accompagner un code de statut HTTP 403.

Exemple de message : le service de métadonnées n'est pas activé sur l'instance fournie.

`unknown_field`

Utilisé lorsqu'un paramètre ou une propriété de requête inconnu est fourni.

Le code d'erreur unknown_field peut accompagner un code de statut HTTP 400.

Exemple de message: la propriété inconnue xyzzy a été spécifiée dans le corps de la demande.