web-dev-qa-db-ja.com

REST APIの検証エラー応答

RESTful APIを設計していますが、検証エラーメッセージに最適な形式は何ですか。

たとえば、アカウント作成エンドポイントはJSONオブジェクトを受け入れます。

user: {
  first_name: string,
  last_name: string,
  address: {
    street: string,
    city: string,
    Zip_code: string
  }
}

私の回答は次の形式になります。

{
    code: 400,  // HTTP code
    message: "Validation failed",  // general message
    type: "validation_failed",  // there are other types of errors as well
    errors: WHAT_DO_I_SHOW_HERE
}

検証エラーメッセージにはいくつかの選択肢があります。

形式1

errors: {
  last_name: "First name is required",
  address: {
    Zip_code: "Zip code is invalid"
  }
}

または、フォーマット2のようにエラーを平坦化します

errors: {
  last_name: "First name is required",
  "address.city": "City is required",
  "address.Zip_code": "Zip code is invalid"
}

または、配列を使用します。各要素には、フィールド名、エラーコード、エラーメッセージ、ネストされたエラーなどを含めることができます。

errors: [
  {
    field: "first_name",
    message: "First name is required",
  },
  {
    field: "address",
    errors: [
      {
        field: "Zip_code",
        message: "Zip code is invalid"
      }
    ]
  }
]

または

errors: [
  {
    field: "first_name",
    message: "First name is required",
  },
  {
    field: "address.Zip_code",
    message: "Zip code is invalid"
  }
]

明らかに、フィールド名はオプションであるため、配列形式はより柔軟であり、複数のフィールドの組み合わせに関連するエラーに対応できます（たとえば、時間間隔の終了時刻は開始時刻より後にする必要があります）。しかし、私の質問は、APIユーザーが消費しやすいのはどれですか？

restapiapi-designweb-apierror-messages
2
sean hawk

あなたはあなたのAPIレイヤーでやりすぎています。最初の検証エラーで失敗し、そのメッセージを返します。

APIのコンシューマーは、完全な検証beforeを呼び出してAPIを実装する必要があります。検証ルールを発行して、APIがこれを実行できるようにする必要があります。

5
Ewan

APIの消費者として、私は最後のオプションを好みます。配列をループし、フィールド（名前が存在する場合）または一般的なエラーボックス（存在しない場合）にエラーメッセージを添付します。

ネストされた配列はコード化の手間がかかり、フォームレベルの検証エラーを許可しないため、以前のオプションはすべて制限されています。

2
Eric Stein