El tipo Status
define un modelo de error lógico que es adecuado para diferentes entornos de programación, incluidas las API REST y API RPC. Es utilizado por gRPC . El modelo de error está diseñado para ser:
- Fácil de usar y entender para la mayoría de los usuarios.
- Lo suficientemente flexible para satisfacer necesidades inesperadas
Descripción general
El mensaje Status
contiene tres datos: código de error, mensaje de error y detalles del error. El código de error debe ser un valor de enumeración de google.rpc.Code
, pero puede aceptar códigos de error adicionales si es necesario. El mensaje de error debe ser un mensaje en inglés dirigido a los desarrolladores que les ayude a comprender y resolver el error. Si se necesita un mensaje de error localizado para el usuario, coloque el mensaje localizado en los detalles del error o localícelo en el cliente. Los detalles del error opcionales pueden contener información arbitraria sobre el error. Hay un conjunto predefinido de tipos de detalles de error en el paquete google.rpc
que se puede utilizar para condiciones de error comunes.
Mapeo de idiomas
El mensaje Status
es la representación lógica del modelo de error, pero no es necesariamente el formato de conexión real. Cuando el mensaje Status
se expone en diferentes bibliotecas de clientes y diferentes protocolos de conexión, se puede asignar de manera diferente. Por ejemplo, es probable que se asigne a algunas excepciones en Java, pero es más probable que se asigne a algunos códigos de error en C.
Otros usos
El modelo de error y el mensaje Status
se pueden usar en una variedad de entornos, con o sin API, para brindar una experiencia de desarrollador consistente en diferentes entornos.
Los usos de ejemplo de este modelo de error incluyen:
Errores parciales. Si un servicio necesita devolver errores parciales al cliente, puede incrustar el
Status
en la respuesta normal para indicar los errores parciales.Errores de flujo de trabajo. Un flujo de trabajo típico tiene varios pasos. Cada paso puede tener un mensaje
Status
para informar errores.Operaciones por lotes. Si un cliente utiliza una solicitud por lotes y una respuesta por lotes, el mensaje
Status
debe usarse directamente dentro de la respuesta por lotes, uno para cada subrespuesta de error.Operaciones asincrónicas. Si una llamada API incorpora una operación asincrónica como resultado de su respuesta, el estado de esas operaciones debe representarse directamente mediante el mensaje
Status
.Inicio sesión. Si algunos errores de API se almacenan en registros, el mensaje
Status
podría usarse directamente después de cualquier eliminación necesaria por razones de seguridad/privacidad.
Representación JSON | |
---|---|
{ "code": number, "message": string, "details": [ { "@type": string, field1: ..., ... } ] } |
Campos | |
---|---|
code | El código de estado, que debe ser un valor de enumeración de |
message | Un mensaje de error para desarrolladores, que debería estar en inglés. Cualquier mensaje de error que vea el usuario debe localizarse y enviarse en el campo |
details[] | Una lista de mensajes que contienen los detalles del error. Existe un conjunto común de tipos de mensajes que pueden utilizar las API. Un objeto que contiene campos de un tipo arbitrario. Un campo adicional |