Status
タイプは、REST API や RPC API などのさまざまなプログラミング環境に適した論理エラー モデルを定義します。 gRPCによって使用されます。エラー モデルは次のように設計されています。
- ほとんどのユーザーにとって使いやすく理解しやすい
- 予期せぬニーズにも柔軟に対応できる
概要
Status
メッセージには、エラー コード、エラー メッセージ、エラーの詳細の 3 つのデータが含まれています。エラー コードはgoogle.rpc.Code
の列挙値である必要がありますが、必要に応じて追加のエラー コードを受け入れることができます。エラー メッセージは、開発者がエラーを理解して解決するのに役立つ、開発者向けの英語メッセージである必要があります。ユーザー向けのローカライズされたエラー メッセージが必要な場合は、ローカライズされたメッセージをエラーの詳細に含めるか、クライアントでローカライズします。オプションのエラー詳細には、エラーに関する任意の情報が含まれる場合があります。パッケージgoogle.rpc
には、一般的なエラー条件に使用できる、事前定義されたエラー詳細タイプのセットがあります。
言語マッピング
Status
メッセージはエラー モデルの論理表現ですが、必ずしも実際のワイヤ形式であるとは限りません。 Status
メッセージが異なるクライアント ライブラリおよび異なるワイヤ プロトコルで公開される場合、異なる方法でマップされる可能性があります。たとえば、Java の一部の例外にマップされる可能性が高くなりますが、C の一部のエラー コードにマップされる可能性が高くなります。
その他の用途
エラー モデルとStatus
メッセージは、API の有無にかかわらず、さまざまな環境で使用でき、さまざまな環境間で一貫した開発者エクスペリエンスを提供します。
このエラー モデルの使用例は次のとおりです。
部分的なエラー。サービスが部分エラーをクライアントに返す必要がある場合、部分エラーを示す
Status
通常の応答に埋め込むことがあります。ワークフローエラー。一般的なワークフローには複数のステップがあります。各ステップには、エラー報告用の
Status
メッセージが含まれる場合があります。バッチ操作。クライアントがバッチ リクエストとバッチ レスポンスを使用する場合、
Status
メッセージは、エラー サブレスポンスごとに 1 つずつ、バッチ レスポンス内で直接使用する必要があります。非同期操作。 API 呼び出しの応答に非同期操作の結果が組み込まれている場合、それらの操作のステータスは、
Status
メッセージを使用して直接表す必要があります。ロギング。一部の API エラーがログに保存されている場合、セキュリティ/プライバシー上の理由で必要な削除の直後に、メッセージ
Status
使用される可能性があります。
JSON表現 | |
---|---|
{ "code": number, "message": string, "details": [ { "@type": string, field1: ..., ... } ] } |
田畑 | |
---|---|
code | ステータス コード。 |
message | 開発者向けのエラー メッセージ。英語である必要があります。ユーザーに表示されるエラー メッセージはすべてローカライズして |
details[] | エラーの詳細を伝えるメッセージのリスト。 API で使用する共通のメッセージ タイプのセットがあります。 任意の型のフィールドを含むオブジェクト。追加フィールド |