Status
Il tipo Status
definisce un modello di errore logico adatto a diversi ambienti di programmazione, tra cui API REST e API RPC. È utilizzato da gRPC. Ogni messaggio Status
contiene tre dati: codice, messaggio di errore e dettagli dell'errore.
Per saperne di più su questo modello di errore e su come utilizzarlo, consulta la Guida alla progettazione dell'API.
Rappresentazione JSON |
{
"code": integer,
"message": string,
"details": [
{
"@type": string,
field1: ...,
...
}
]
} |
Campi |
code |
integer
Il codice di stato, che deve essere un valore enum pari a google.rpc.Code .
|
message |
string
Un messaggio di errore rivolto agli sviluppatori, che deve essere in inglese. Qualsiasi messaggio di errore rivolto agli utenti deve essere localizzato e inviato nel campo google.rpc.Status.details oppure deve essere localizzato dal client.
|
details[] |
object
Un elenco di messaggi con i dettagli dell'errore. Le API possono utilizzare un insieme comune di tipi di messaggi. Un oggetto che contiene campi di tipo arbitrario. Un campo aggiuntivo "@type" contiene un URI che identifica il tipo. Esempio: { "id": 1234, "@type": "types.example.com/standard/id" } .
|
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2024-08-21 UTC.
[null,null,["Ultimo aggiornamento 2024-08-21 UTC."],[[["The `Status` type is a structured approach to define errors in APIs, containing an error code, message, and details for analysis."],["The error model utilizes a JSON representation with fields for code, message, and an array for detailed error information."],["Developers can integrate this model into REST APIs and RPC APIs, referencing the `google.rpc.Code` enum for standardized error codes."],["Error messages are intended for developers and should be in English, while user-facing messages should be handled separately via localization."],["The `details` field provides flexibility by allowing arbitrary objects to convey specific error information using a URI for type identification."]]],[]]