私は現在、RESTful APIを構築する初期段階にあり、ビジネスルールの検証を正しく処理するために前後しています。ビジネスルールの検証用にRESTful APIで意味のあるHTTP応答コードを決定する
私はWeb API 2を使用していますが、現在はモデルの検証を処理するためにIValidatableObjectを使用しています。たとえば、必要なフィールドが見つからない場合、「400 Bad Request」と「ModelState」が返されます。
IValidatableObjectのメソッドPublic IEnumerable<ValidationResult> Validate(ValidationContext validationContext)にビジネス・ルールの妥当性検査を追加し始め、検証をパスしなかったビジネス・ルールを説明するメッセージとともに「400 Bad Request」を戻し続けました。その後、私は一歩踏み出し、「ビジネスルールはモデルの検証とは異なり、リクエストは完全に有効です。私は400を返すべきではありません」と考えました。
ここでは、ビジネスルールの検証をモデル検証からドメインロジックに移行する予定です。このため、正しいステータスコードだけでなく、クライアントが表示する適切なメッセージをどのように判断するのか、私は考えていました。
私は403 Forbiddenと422 Unprocessable Entityの間で引き裂かれ、422に向かって傾いています。
ここで、複数のビジネスルールに失敗したリクエストを作成し、422とエラーメッセージのコレクションを返します。私は、クライアントがエラーを理解し、メッセージを私の応答に表示するだけでなく、どのように見えるかを伝えることができるようにしたい。
- 失敗したビジネスに最も適したHTTPステータスコードはどれですか。
- 返信エラーメッセージに関するベストプラクティスは何ですか？
422.xを返し、それぞれの.xを文書化することで、クライアントは何をすべきか分かりますか？それは、リクエストごとに1つのエラーだけを返すという制限を私に残しているようです。
エラーコードを定義し、エラーメッセージを表示する必要がありますか？例：
{
"Errors": [
{ "Error": { "Code": "E0001", "Message": "You failed business rule 1" } },
{ "Error": { "Code": "E0002", "Message": "You failed business rule 2" } }
]
}
フィードバックは素晴らしいです！ありがとう！