El tipo de Status define un modelo de error lógico que es adecuado para entornos de programación diferentes, incluidas las API de REST y las API de RPC. Lo usa gRPC. El modelo de errores está diseñado para ser de la siguiente forma:
Fácil de usar y entender para la mayoría de los usuarios
Lo suficientemente flexible para satisfacer necesidades inesperadas
Resumen
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 al desarrollador que ayude a los desarrolladores a entender y resolver el error. Si se necesita un mensaje de error localizado orientado al usuario, coloca el mensaje localizado en los detalles del error o localízalo en el cliente. Los detalles opcionales del error pueden contener información arbitraria sobre el error. Hay un conjunto predefinido de tipos de detalles del error en el paquete google.rpc que puede usarse para condiciones de error comunes.
Asignación de idiomas
El mensaje Status es la representación lógica del modelo de errores, pero no es necesariamente el formato de conexión real. Cuando el mensaje Status se expone en diferentes bibliotecas cliente y diferentes protocolos de conexión, puede asignarse de manera diferente. Por ejemplo, probablemente se asignará 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 pueden usarse en una variedad de entornos, con o sin API, para proporcionar una experiencia de desarrollador consistente en diferentes entornos.
Los ejemplos de usos de este modelo de error incluyen lo siguiente:
Errores parciales. Si el servicio debe mostrar errores parciales al cliente, puede incorporar 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 los informes de errores.
Operaciones por lotes. Si un cliente usa una solicitud por lotes y una respuesta por lotes, el mensaje Status debe usarse directamente dentro de la respuesta por lotes y debe haber uno para cada respuesta secundaria de error.
Operaciones asíncronas. Si una llamada a la API incorpora los resultados de la operación asíncrona en su respuesta, el estado de esas operaciones debe representarse directamente mediante el uso del mensaje Status.
Si algunos errores de la API se almacenan en los registros, el mensaje Status podría usarse directamente después de cualquier eliminación necesaria por razones de seguridad o privacidad.
El código de estado, que debe ser un valor enum de google.rpc.Code.
message
string
Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error dirigido al usuario debe localizarse y enviarse al campo google.rpc.Status.details; o el cliente debe localizarlo.
details[]
object
Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API.
Un objeto que contiene campos de un tipo arbitrario. Un campo adicional "@type" contiene una URI que identifica el tipo. Ejemplo: { "id": 1234, "@type": "types.example.com/standard/id" }.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-25 (UTC)"],[[["\u003cp\u003eThe \u003ccode\u003eStatus\u003c/code\u003e type is a versatile error model suitable for various programming environments, including REST and RPC APIs, designed for simplicity and flexibility.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eStatus\u003c/code\u003e message comprises three key components: an error code (ideally from \u003ccode\u003egoogle.rpc.Code\u003c/code\u003e), a developer-facing English error message, and optional error details.\u003c/p\u003e\n"],["\u003cp\u003eThis error model can be utilized in multiple ways beyond direct API errors, such as partial errors, workflow errors, batch operations, asynchronous operations, and logging.\u003c/p\u003e\n"],["\u003cp\u003eThe JSON representation of \u003ccode\u003eStatus\u003c/code\u003e includes \u003ccode\u003ecode\u003c/code\u003e, \u003ccode\u003emessage\u003c/code\u003e, and \u003ccode\u003edetails\u003c/code\u003e, where details is an array of objects, each with a \u003ccode\u003e@type\u003c/code\u003e field to define its type.\u003c/p\u003e\n"]]],[],null,["# Status\n\n- [JSON representation](#SCHEMA_REPRESENTATION)\n\nThe `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). The error model is designed to be:\n\n- Simple to use and understand for most users\n- Flexible enough to meet unexpected needs\n\n### Overview\n\nThe `Status` message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of `google.rpc.Code`, but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers *understand* and *resolve* the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package `google.rpc` that can be used for common error conditions.\n\n### Language mapping\n\nThe `Status` message is the logical representation of the error model, but it is not necessarily the actual wire format. When the `Status` message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.\n\n### Other uses\n\nThe error model and the `Status` message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.\n\nExample uses of this error model include:\n\n- Partial errors. If a service needs to return partial errors to the client, it may embed the `Status` in the normal response to indicate the partial errors.\n\n- Workflow errors. A typical workflow has multiple steps. Each step may have a `Status` message for error reporting.\n\n- Batch operations. If a client uses batch request and batch response, the `Status` message should be used directly inside batch response, one for each error sub-response.\n\n- Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the `Status` message.\n\n- Logging. If some API errors are stored in logs, the message `Status` could be used directly after any stripping needed for security/privacy reasons.\n\n| JSON representation ||\n|------------------------------------------------------------------------------------------------------|---|\n| ``` { \"code\": number, \"message\": string, \"details\": [ { \"@type\": string, field1: ..., ... } ], } ``` |\n\n| Fields ||\n|-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `code` | `number` The status code, which should be an enum value of `google.rpc.Code`. |\n| `message` | `string` A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details](/rcs-business-messaging/reference/rest/v1/Status#FIELDS.details) field, or localized by the client. |\n| `details[]` | `object` A list of messages that carry the error details. There is a common set of message types for APIs to use. An object containing fields of an arbitrary type. An additional field `\"@type\"` contains a URI identifying the type. Example: `{ \"id\": 1234, \"@type\": \"types.example.com/standard/id\" }`. \u003cbr /\u003e |"]]
