O tipo Status define um modelo de erro lógico que é adequado a diferentes ambientes de programação, incluindo APIs REST e RPC. É usado por gRPC. O modelo de erro foi projetado para ser:
simples de usar e entender para a maioria dos usuários;
flexível o suficiente para atender às necessidades imprevistas.
Visão geral
A mensagem Status contém três dados: código de erro, mensagem de erro e detalhes do erro. O código de erro precisa ser um valor de enum google.rpc.Code, mas pode aceitar códigos de erro adicionais, se necessário. A mensagem de erro é uma mensagem em inglês que ajuda o desenvolvedor a entender e resolver o erro. Se uma mensagem de erro localizada para o usuário for necessária, coloque-a nos detalhes do erro ou faça a localização no cliente. Os detalhes opcionais do erro podem conter informações arbitrárias sobre ele. Há um conjunto predefinido de tipos de detalhes de erro no pacote google.rpc que pode ser usado para condições de erro comuns.
Mapeamento de linguagem
A mensagem Status é a representação lógica do modelo de erro, mas não é necessariamente o formato de transmissão real. Quando a mensagem Status é exposta em diferentes bibliotecas de cliente e protocolos de transmissão, ela pode ser mapeada de maneira diferente. Por exemplo, talvez ela seja mapeada para algumas exceções em Java, mas com probabilidade maior para alguns códigos de erro em C.
Outros usos
O modelo de erro e a mensagem Status podem ser usados em vários ambientes, com ou sem APIs, para proporcionar uma experiência de desenvolvedor consistente em diferentes ambientes.
Os exemplos de uso desse modelo de erro incluem:
erros parciais. Se um serviço precisar retornar erros parciais ao cliente, ele poderá incorporar o Status na resposta normal para indicar os erros parciais.
erros de fluxo de trabalho. Um fluxo de trabalho típico tem várias etapas. Cada etapa pode ter uma mensagem Status para o relatório de erros.
Operações em lote. Se um cliente usar solicitação em lote e resposta em lote, a mensagem Status será usada diretamente dentro da resposta em lote, uma para cada sub-resposta de erro.
Operações assíncronas. Se uma chamada de API incorpora resultados de operações assíncronas na resposta, o status dessas operações precisa ser representado diretamente usando a mensagem Status.
Geração de registros. Quando alguns erros de API são armazenados em registros, a mensagem de Status pode ser usada diretamente após qualquer remoção necessária por motivos de segurança/privacidade.
O código de status, que precisa ser um valor de enumeração de google.rpc.Code.
message
string
Uma mensagem de erro em inglês para o desenvolvedor. Qualquer mensagem de erro para o usuário precisa ser localizada e enviada no campo google.rpc.Status.details, ou localizada pelo cliente.
details[]
object
Uma lista de mensagens com os detalhes do erro. Há um conjunto comum de tipos de mensagens para as APIs usarem.
Um objeto contendo campos de um tipo arbitrário. Um campo adicional "@type" contém uma URI que identifica o tipo. Exemplo: { "id": 1234, "@type": "types.example.com/standard/id" }.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-03-04 UTC."],[],[],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](/natural-language/docs/reference/rest/Shared.Types/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."]]