Restful API を作成していて、エラー メッセージを返す必要がありますが、どのルートに進むべきかわかりません。
ルート 1 - HTTP ステータス
クライアントが不正なデータを送信したときに HTTP エラー ステータスを使用する
HTTP ステータス コードは、RESTful であると主張するすべての Web サービス実装で絶対に使用する必要があります。仕様の中核となる原則は、Web を活用および拡張して、表現状態の転送を完全にサポートすることです。既存の Web インフラストラクチャとの相互運用を可能にするために、REST 実装は、適切な HTTP ステータス コードを介してリクエストのステータスを示す必要があります。例えば:
200 - OK
201 - コンテンツが作成されました
401 - 無許可
403 - 禁止されてい
ます 500 - サーバー エラー
501 - 実装されていません
これらのステータスの多くで応答する場合、HTTP 仕様では、応答本文にエンティティ表現を含めることも許可されています。「通常の」エラーのない応答の場合、この表現は通常、HTTP 要求によって「操作」されているエンティティになります。エラー応答の場合、表現が含まれている場合は、発生したエラーに関する詳細情報を提供する必要があります。ここで、オプション 2 に進みます。
ルート 2 - JSON の成功またはエラーの失敗
APIはjsonを返し、httpヘッダー200ですべてを返すことを検討していますが、JSONでエラーと成功を処理します
すべての応答に対して 200 OK を返すべきではありません。多くの適切に実装された HTTP クライアントは、応答のステータス コードに依存して、成功したかどうかを判断します。常に 200 OK で応答すると、サード パーティのクライアント ライブラリが受信データを誤って処理する可能性があります。また、エラーが実際に発生したかどうかを判断するために、応答本文を解析する必要があります。
そうは言っても、発生したエラーに関する追加情報を追加することは非常に役立つ可能性があるため、応答本文に追加することを検討してください。提案された形式は問題ないように見えますが、正直なところ、status
HTTP ステータス コードを適切に使用すると仮定すると、この要素は冗長です。もっと似たもの:
{
"message": "Model validation error",
"data": [
"user name required",
"user email required"
]
}