Package google.rpc

Index

• Code (enum)
• Status (message)

Code

Les codes d'erreur canoniques pour les API de gRPC.

Parfois, plusieurs codes d'erreur peuvent s'appliquer. Les services doivent renvoyer le code d'erreur le plus spécifique qui s'applique. Par exemple, préférez OUT_OF_RANGE à FAILED_PRECONDITION si les deux codes s'appliquent. De même, préférez NOT_FOUND ou ALREADY_EXISTS à FAILED_PRECONDITION.

Enums
OK	Pas une erreur, affiché en cas de réussite Mise en correspondance HTTP : 200 OK
CANCELLED	L'opération a été annulée, généralement par l'appelant. Mise en correspondance HTTP : 499 Le client a fermé la requête
UNKNOWN	Erreur inconnue. Par exemple, cette erreur peut s'afficher lorsqu'une valeur Status reçue d'un autre espace d'adressage appartient à un espace d'erreur inconnu dans cet espace d'adressage. De plus, les erreurs des API qui ne renvoient pas suffisamment d'informations relatives aux erreurs peuvent être converties dans cette erreur. Mise en correspondance HTTP : 500 Erreur de serveur interne
INVALID_ARGUMENT	Le client a spécifié un argument non valide. Notez que cette erreur diffère de FAILED_PRECONDITION. INVALID_ARGUMENT indique les arguments problématiques quel que soit l'état du système (par exemple, un nom de fichier incorrect). Mise en correspondance HTTP : 400 Requête incorrecte
DEADLINE_EXCEEDED	Le délai a expiré avant que l'opération puisse se terminer. Pour les opérations qui modifient l'état du système, cette erreur peut être affichée même si l'opération s'est terminée avec succès. Par exemple, une réponse réussie d'un serveur aurait pu être retardée suffisamment longtemps pour que le délai expire. Mappage HTTP : 504 Passerelle hors délai
NOT_FOUND	Une entité demandée (fichier ou répertoire, par exemple) est introuvable. Remarque pour les développeurs de serveurs : NOT_FOUND peut être utilisé si une requête est refusée pour toute une classe d'utilisateurs, telle que le déploiement progressif des fonctionnalités ou la liste d'autorisation non documentée. Si une requête est refusée pour certains utilisateurs appartenant à une classe d'utilisateurs, telle que le contrôle des accès basé sur l'utilisateur, PERMISSION_DENIED doit être utilisé. Mise en correspondance HTTP : 404 Page introuvable
ALREADY_EXISTS	L'entité qu'un client a tenté de créer (par exemple, un fichier ou un répertoire) existe déjà. Mise en correspondance HTTP : 409 Conflit
PERMISSION_DENIED	L'appelant n'a pas l'autorisation d'exécuter l'opération spécifiée. PERMISSION_DENIED ne doit pas être utilisé pour les rejets causés par l'épuisement d'une ressource (utilisez plutôt RESOURCE_EXHAUSTED pour ces erreurs). PERMISSION_DENIED ne doit pas être utilisé si l'appelant ne peut pas être identifié (utilisez plutôt UNAUTHENTICATED pour ces erreurs). Ce code d'erreur n'implique pas que la requête soit valide ni que l'entité demandée existe ou qu'elle répond à d'autres pré-requis. Mise en correspondance HTTP : 403 Accès interdit
UNAUTHENTICATED	La requête ne dispose pas d'identifiants d'authentification valides pour l'opération. Mise en correspondance HTTP : 401 Accès non autorisé
RESOURCE_EXHAUSTED	Certaines ressources ont été épuisées ; par exemple, un quota par utilisateur a été atteint ou le système de fichiers dans son intégralité manque d'espace. Mise en correspondance HTTP : 429 Requêtes trop nombreuses
FAILED_PRECONDITION	L'opération a été rejetée car le système n'est pas dans un état requis pour exécuter l'opération. Par exemple, le répertoire à supprimer n'est pas vide, une opération rmdir est appliquée à un emplacement qui n'est pas un répertoire, etc. Les développeurs de services peuvent suivre les instructions suivantes pour choisir entre FAILED_PRECONDITION, ABORTED et UNAVAILABLE : (a) Utilisez UNAVAILABLE si le client ne peut relancer que l'appel ayant échoué. (b) Utilisez ABORTED si le client doit effectuer une nouvelle tentative à un niveau supérieur (par exemple, lorsqu'un test-and-set spécifié par le client échoue, indiquant que le client doit redémarrer une séquence lecture-modification-écriture). (c) Utilisez FAILED_PRECONDITION si le client ne doit pas effectuer de nouvelle tentative tant que l'état du système n'a pas été explicitement corrigé. Par exemple, si un "rmdir" échoue parce que le répertoire n'est pas vide, FAILED_PRECONDITION doit être affiché, car le client ne doit pas effectuer de nouvelle tentative à moins que les fichiers ne soient supprimés du répertoire. Mise en correspondance HTTP : 400 Requête incorrecte
ABORTED	L'opération a été abandonnée, généralement en raison d'un problème de simultanéité, tel qu'un échec de vérification du séquenceur ou un abandon de transaction. Consultez les instructions ci-dessus pour choisir entre FAILED_PRECONDITION, ABORTED et UNAVAILABLE. Mise en correspondance HTTP : 409 Conflit
OUT_OF_RANGE	L'opération a été tentée au-delà de la plage valide. Par exemple, rechercher ou lire après la fin du fichier. Contrairement à INVALID_ARGUMENT, cette erreur indique un problème pouvant être résolu si l'état du système change. Par exemple, un système de fichiers 32 bits génère INVALID_ARGUMENT s'il est invité à lire avec un décalage qui n'est pas compris dans la plage [0,2^32-1], mais génère OUT_OF_RANGE s'il est invité à lire avec un décalage qui dépasse la taille du fichier actuel. Il existe des cas où FAILED_PRECONDITION et OUT_OF_RANGE se chevauchent. Nous vous recommandons d'utiliser OUT_OF_RANGE (l'erreur la plus spécifique) lorsque celle-ci s'applique afin que les appelants qui itèrent dans un espace puissent facilement rechercher une erreur OUT_OF_RANGE pour détecter le moment où ils ont terminé. Mise en correspondance HTTP : 400 Requête incorrecte
UNIMPLEMENTED	L'opération n'est pas implémentée ou n'est pas prise en charge/activée dans ce service. Mise en correspondance HTTP : 501 Non implémenté
INTERNAL	Erreurs internes. Cela signifie que certains invariants attendus par le système sous-jacent n'ont pas été respectés. Ce code d'erreur est réservé aux erreurs graves. Mise en correspondance HTTP : 500 Erreur de serveur interne
UNAVAILABLE	Le service est actuellement indisponible. Il s'agit probablement d'une condition temporaire qui peut être corrigée en réessayant après avoir laissé passer un intervalle entre les tentatives. Consultez les instructions ci-dessus pour choisir entre FAILED_PRECONDITION, ABORTED et UNAVAILABLE. Mise en correspondance HTTP : 503 Service non disponible
DATA_LOSS	Perte ou corruption de données irrécupérable. Mise en correspondance HTTP : 500 Erreur de serveur interne

État

Le type Status définit un modèle d'erreur logique adapté aux différents environnements de programmation, y compris les API REST et RPC. Il est utilisé par le protocole gRPC. Le modèle d'erreur est conçu pour être :

• facile à utiliser et à comprendre pour la plupart des utilisateurs ;
• suffisamment flexible pour répondre à des besoins inattendus.

Présentation

Le message Status contient trois éléments de données : un code d'erreur, un message d'erreur et les détails de l'erreur. Le code d'erreur doit être une valeur d'énumération google.rpc.Code, mais des codes d'erreur supplémentaires peuvent également être acceptés au besoin. Le message d'erreur doit être un message en anglais destiné aux développeurs, les aidant à comprendre et à résoudre l'erreur. Si un message d'erreur localisé destiné à l'utilisateur est nécessaire, vous pouvez le placer dans les détails de l'erreur ou le localiser dans le client. Les détails d'erreur facultatifs peuvent contenir des informations arbitraires sur l'erreur. Il existe un ensemble prédéfini de types de détails d'erreur dans le package google.rpc, qui peut être utilisé pour les conditions d'erreur courantes.

Mappage linguistique

Le message Status est la représentation logique du modèle d'erreur, mais il ne s'agit pas nécessairement du format de communication réel. Lorsque le message Status est exposé dans différentes bibliothèques clientes et divers protocoles de communication, il peut être mappé différemment. Par exemple, il sera sans doute mappé à des exceptions en Java, mais plus probablement à des codes d'erreur en C.

Autres utilisations

Le modèle d'erreur et le message Status peuvent être utilisés dans divers environnements, avec ou sans API, pour offrir aux développeurs une expérience cohérente.

Voici quelques exemples d'utilisation de ce modèle d'erreur :

• Erreurs partielles. Si un service doit renvoyer des erreurs partielles au client, il peut intégrer le message Status dans la réponse normale pour les indiquer.

• Erreurs de flux de travail. Un flux de travail typique comporte plusieurs étapes. Chaque étape peut inclure un message Status signalant les erreurs.

• Opérations par lot. Si un client emploie des requêtes et des réponses par lot, le message Status doit être utilisé directement dans la réponse par lot pour chaque sous-réponse d'erreur.

• Opérations asynchrones. Si un appel d'API intègre les résultats d'une opération asynchrone dans la réponse, l'état de ces opérations doit être représenté directement à l'aide du message Status.

• Journalisation. Si certaines erreurs d'API sont consignées dans des journaux, le message Status peut être utilisé directement après toute suppression requise pour des raisons de sécurité/confidentialité.

Champs
code	int32 Code d'état, qui doit être une valeur d'énumération de google.rpc.Code.
message	string Message d'erreur destiné au développeur, qui doit être en anglais. Tout message d'erreur destiné aux utilisateurs doit être localisé et envoyé dans le champ google.rpc.Status.details, ou localisé par le client.
details[]	Any Liste de messages comportant les détails de l'erreur. Il existe un ensemble commun de types de message utilisable par les API.