REST APIでの検証エラーの応答

Question

私はRESTful APIを設計しており、検証エラーメッセージに最適なフォーマットが何か不思議です。

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

私の応答は次の形式になります：

例えば

は、アカウントの作成エンドポイントは、JSONオブジェクトを受け入れ

：

{ 
    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" 
    } 
] 

明らかフィールド名はオプションであるので、アレイフォーマットは、より柔軟性があるので、複数の金融商品取引法の組み合わせに関連するエラーを収容することができds（例えば、時間間隔の終了時間は開始時間の後でなければならない）。しかし、私の質問は、どちらがAPIユーザーが簡単に消費できるのでしょうか？

Answer 1

私はフロントエンドのHTMLで作業していますが、私はエラーフォーマット2を平坦化したいと思っています。私はそれを調べたり、エラーを表示するのが簡単です。

オープンは他人

Answer 2

は、だからあなたのクライアントは、HTTPステータスコードをチェックしなければならないの意見を聞くために、それは200 OKではない場合、彼らはエラーを調べてモデルオブジェクトにそのJSONをデシリアライズする必要があるだろうか？異なる種類のエラー（BadRequest、Conflict、DB関連のエラーなど）がある場合はどうなりますか？

なぜ「場合」今のコースの両方が同時に発生しないことがありますが、それでも、あなたは可能な限りジェネリックとして、あなたのAPIをしたい、束ねからあなたの顧客を惜しまするために、一般的な

errors: [ 
    { 
    type: "ValidationError", // or an int value from an Enum 
    message: "First name is required", 
    }, 
    { 
    type: "DBError", 
    message: "Connection not found" // you might want to say something more generic here, but at the same time if you don't treat it at all it will bubble up as a 500 internal server error 
    } 
] 

を返しませんコード内にある。