DBで見つかった不良データのHTTPレスポンスステータスコード

Question

Web APIの1つで返されるJSON応答に、ビジネスで必須と見なされる最小限のフィールドセットが含まれていると期待しています。

これは、契約を尊重しない悪いデータがデータベースにある場合に適していますか？HTTP status code

現時点では500を使用していますが、改善が必要な場合もあります（また、サービスの前にワニスを入れて500を503 Service Unavailableに変換するため）。

例：

{ 
    "id": "123", 
    "message": "500 - Exception during request processing. Cause: subtitles is a required field of class Movie and cannot be empty", 
    "_links": { 
    "self": { 
     "href": "/products/movies/123" 
    } 
    } 
} 

おかげ

Answer 1

500内部サーバーエラーは、問題は、サーバー側から、本質的であると正直に言うと、ここで十分のようですし、それからやって間違ったを反映するものではありません。クライアント側。

Answer 2

400はBADリクエストを意味しますが、リクエストには何も悪いことはないので、使用しないでください。

500は、予期せぬことが起こった場合のサーバーエラーを意味します。コードが破損し、銀河がクラッシュしました。悪いデータはそれの原因ではありません。

あなたには悪いデータがありますので、自由に使い分けることができます。

最初の質問は、悪いデータをどうしますか？

1. この場合、リクエストは正常ですが返信するデータがないことを意味する204を返します。 404はエンドポイントが存在しないという意味でデータが存在しないため404を返さないでしょう。

2. 誰かが修正している間に、メインのデータベースからtempデータに移動することができます。

どちらの方法でも、悪いデータを返さず、クライアントがそのデータが悪い理由を気にしません。すべてのクライアントは、データがあるかどうかに関係しています。 重要と思われるフィールドがデータに欠落していることをクライアントが気にする必要があるのはなぜですか？

もう1つアプローチして、データを返すことができます。

結論：悪いデータをどのように処理しているのかを判断し、クライアントに何らかの責任を負いません。