Status

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

number

ステータス コード。 google.rpc.Codeの列挙値である必要があります。

message

string

開発者向けのエラー メッセージ。英語である必要があります。ユーザーに表示されるエラー メッセージはすべてローカライズしてgoogle.rpc.Status.detailsフィールドに送信するか、クライアントによってローカライズする必要があります。

details[]

object

エラーの詳細を伝えるメッセージのリスト。 API で使用する共通のメッセージ タイプのセットがあります。

任意の型のフィールドを含むオブジェクト。追加フィールド"@type"タイプを識別する URI が含まれます。例: { "id": 1234, "@type": "types.example.com/standard/id" } 。