有効なリクエストに対して適切なREST応答コードは何ですか？ただし、データは空ですか？

たとえば、GETリクエストを実行しusers/9たが、ID＃9のユーザーがいない。最良の応答コードはどれですか？

• 200 OK
• 202受け入れ
• 204コンテンツなし
• 400不正な要求
• 404お探しのページが見つかりませんでした

TL; DR：使用 404

このブログを参照してください。それはそれを非常によく説明しています。

に関するブログのコメントの要約204：

1. 204 No Content ブラウザの応答コードとしてはそれほど有用ではありません（HTTP仕様によると、ブラウザはそれを「ビューを変更しない」応答コードとして理解する必要があります）。
2. 204 No Content ある何かを返すことなく、成功を示す場合がありますAJAX Webサービスのための非常に便利な、しかし。（特に、フィードバックを必要としない、DELETEまたはPOSTsの場合）。

したがって、あなたの質問に対する答えは404あなたのケースでの使用です。204は、に応答してブラウザーに戻らないことが多い特殊な応答コードですGET。

204and よりさらに適切ではない他の応答コード404：

1. 200正常にフェッチされたものの本文とともに返されます。取得するエンティティが存在しない場合は適切ではありません。
2. 202サーバーがオブジェクトの処理を開始したが、オブジェクトの準備がまだ整っていない場合に使用されます。確かにここではそうではありません。GET要求に応じてユーザー9の構築を開始しておらず、開始もしていません。それはあらゆる種類のルールに違反します。
3. 400正しくフォーマットされていないHTTPリクエストへの応答で使用されます（たとえば、不正な形式のhttpヘッダー、誤った順序のセグメントなど）。これはほぼ確実に、使用しているフレームワークによって処理されます。独自のサーバーを最初から作成するのでない限り、これに対処する必要はありません。編集：新しいRFCでは、意味的に無効なリクエストに400を使用できるようになりました。

ウィキペディアのHTTPステータスコードの説明は特に役立ちます。また、www.w3.orgのHTTP / 1.1 RFC2616ドキュメントで定義を確認することもできます。

空のデータを持つ204または200を支持して404に強く反対します。または、少なくとも1つは404で応答エンティティを使用する必要があります。

リクエストが受信され、適切に処理されました-サーバー上のアプリケーションコードをトリガーしたため、実際にクライアントエラーであるとは言えず、クライアントエラーコード（4xx）のクラス全体が適切ではありません。

さらに重要なこととして、404は多くの技術的な理由で発生する可能性があります。たとえば、サーバーで一時的に非アクティブ化またはアンインストールされているアプリケーション、プロキシ接続の問題など。したがって、クライアントは「空の結果セット」を意味する404と「サービスが見つかりません。後で再試行してください」を意味する404を区別できません。

これは致命的となる可能性があります。会社の会計サービスで、年次ボーナスの対象となるすべての従業員を一覧表示するとします。残念ながら、一度呼び出されると404が返されます。それは、誰もボーナスの支払い期限がないことを意味しますか、それとも、アプリケーションが現在新しいデプロイメントのためにダウンしているのですか？

->データの品質を重視するアプリケーションの場合、応答エンティティなしの404はほとんど問題ありません。

また、多くのクライアントフレームワークは、これ以上質問されずに例外をスローすることで404に応答します。これにより、クライアント開発者は、その例外をキャッチして評価し、その結果に基づいて、たとえば監視コンポーネントによってピックアップされたエラーとしてログに記録するか、それを無視するかを決定します。それも私にはきれいに思えません。

204に対する404の利点は、要求されたリソースが見つからなかった理由に関する情報を含む応答エンティティを返すことができることです。しかし、それが本当に関連している場合は、200 OK応答の使用を検討し、ペイロードデータでのエラー応答を可能にするようにシステムを設計することもできます。あるいは、404応答のペイロードを使用して、構造化された情報を呼び出し元に返すこともできます。たとえば、XMLまたはJSONの代わりに解析できるhtmlページを受け取った場合、それは呼び出し側の観点からは有効な「結果なし」の応答ではなく、技術的な問題があったことを示す良い指標です。または、そのためにHTTP応答ヘッダーを使用することもできます。

それでも私は空の応答を持つ204または200を好むでしょう。このようにして、リクエストの技術的な実行のステータスがリクエストの論理的な結果から分離されます。2xxは、「技術的な実行に問題はありません。これが結果です。対処してください」という意味です。

ほとんどの場合、空の結果が受け入れられるかどうかを決めるのはクライアントに任せるべきだと思います。適切な技術的実行にもかかわらず、応答エンティティなしで404を返すことにより、クライアントは、ケースを単にエラーではないエラーと見なすことを決定できます。

別の簡単な類推：「結果が見つかりません」の場合に404​​を返すことは、SQLクエリが結果を返さなかった場合にDatabaseConnectionExceptionをスローするようなものです。それは仕事を成し遂げることができますが、有効な結果と間違われるであろう同じ例外を投げる多くの可能な技術的原因があります。

最初は、204が理にかなっていると思いましたが、話し合いの結果、404が唯一の正しい応答だと思います。次のデータを検討してください。

ユーザー：ジョン、ピーター

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /users/kyle              404     Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

背景：

1. 検索は配列を返しますが、一致はありませんでしたが、コンテンツ：空の配列が含まれています。

2. もちろん、404はリクエストされたサーバーでサポートされていないURLで最もよく知られていますが、欠落しているリソースは実際には同じです。はと一致し
   ています/users/:nameがusers/kyle、ユーザーKyleは使用可能なリソースがないため、404が引き続き適用されます。これは検索クエリではなく、動的URLによる直接参照なので、404です。

とにかく、私の2セント:)

リソースが存在することが期待されているが、それが空である可能性がある場合、モノが空であることを示す表現で200 OKを取得する方が簡単かもしれないと私は主張します。

したがって、/ thingsが200を返し、{"Items"：[]}を返すと、何もない204を返すよりも、0のアイテムを含むコレクションは、1つを含むコレクションと同じように扱うことができるため、より多くのアイテム。

PUTとDELETEには、204 No Contentをそのまま残しておきますが、実際には有用な表現がない場合があります。

/ thing / 9が実際に存在しない場合は、404が適切です。

以前のプロジェクトでは、404を使用しました。ユーザー9がいない場合、オブジェクトは見つかりませんでした。したがって、404 Not Foundが適切です。

オブジェクトが存在するがデータがない場合、204コンテンツなしが適切です。あなたの場合、オブジェクトは存在しないと思います。

w3の投稿によると、

200 OK

リクエストは成功しました。応答で返される情報は、要求で使用されるメソッドに依存します

202受け入れ

リクエストは処理のために受け入れられましたが、処理は完了していません。

204コンテンツなし

サーバーは要求を満たしましたが、エンティティー本体を返す必要はなく、更新されたメタ情報を返したい場合があります。

400不正な要求

不正な構文のため、サーバーはリクエストを理解できませんでした。クライアントは変更なしでリクエストを繰り返さないでください

401無許可

リクエストにはユーザー認証が必要です。応答にはWWW-Authenticateヘッダーフィールドを含める必要があります

404お探しのページが見つかりませんでした

サーバーは、Request-URIに一致するものを検出しませんでした。状態が一時的であるか永続的であるかは示されません

要約または簡略化するには、

2xx：オプションのデータ：整形式URI：基準はURIの一部ではありません：基準がオプションの場合、@ RequestBodyで指定でき、@ RequestParamは2xxにつながるはずです。例：名前/ステータスによるフィルタリング

4xx：予期されるデータ：整形式のURIではありません：基準はURIの一部です：@PathVariableでのみ指定できる基準が必須の場合、4xxにつながるはずです。例：一意のIDによる検索。

したがって、質問された状況の場合： "users / 9"は4xx（おそらく404）になりますが、 "users？name = superman"は2xx（おそらく204）になるはずです

質問が2つあります。タイトルに1つ、例に1つ。これは部分的に、どの対応が適切であるかについての論争の量につながったと思います。

質問のタイトルは空のデータについて尋ねます。空のデータはまだデータですが、データがないとは異なります。したがって、これは、おそらくからの結果セット、つまりリストの要求を示唆してい/usersます。リストが空の場合もリストであるため、204（コンテンツなし）が最適です。ユーザーのリストを要求し、ユーザーのリストが提供されましたが、たまたまコンテンツがありません。

代わりに、提供される例では、特定のオブジェクト、ユーザーについて尋ねます/users/9。ユーザー＃9が見つからない場合、ユーザーオブジェクトは返されません。特定のリソース（ユーザーオブジェクト）を要求したが、見つからなかったために与えられなかったため、404が適切である。

これを解決する方法は、条件文を追加せずに期待どおりに応答を使用できる場合は204を使用し、そうでない場合は404を使用することだと思います。

私の例では、コンテンツがあるかどうかを確認せずに空のリストを反復処理できますが、何かを壊したり、nullかどうかを確認するチェックを追加したりしないと、nullオブジェクトにユーザーオブジェクトデータを表示できません。

もちろん、必要に応じてnullオブジェクトパターンを使用してオブジェクトを返すこともできますが、それは別のスレッドでの議論です。

問題を調べた後、404なぜ使用すべきではないのですか？

RFC 7231に基づくと、正しいステータスコードは204

上記のアンサーでは、1つの小さな誤解に気づきました。

1.-リソースは次のとおりです。 /users

2.- /users/8はリソースではありません。これは/users、ルートパラメータを持つリソースです。8、コンシューマはそれを認識できず、違いを知らないかもしれませんが、パブリッシャは知っており、これを知っている必要があります。限目。

そう：

RFCに基づく：404はリソース/usersが見つかったために正しくあり8ませんが、パラメーターを使用して実行されたロジックcontentは応答として返すものを見つけられなかったため、正しい答えは次のとおりです。204

ここでの要点は404、内部ロジックを処理するためのリソースさえ見つからなかったことです。

204です：リソースを見つけました、ロジックは実行されましたが、ルートパラメータで指定された基準を使用してデータを見つけられなかったため、何も返すことができません。申し訳ありませんが、基準を確認して、もう一度電話してください。

200：はい、リソースを見つけました。ロジックが実行されました（Imが何も返すことを強制されていない場合でも）。これを取得して、自由に使用します。

205：（GET応答の最良のオプション）リソースが見つかり、ロジックが実行されました。コンテンツがいくつかあります。それをうまく使用してください。ところで、ビューでこれを共有する場合は、ビューを更新してください。それを表示します。

それが役に立てば幸い。

既存の回答で詳しく説明されていないのは、パスパラメータとクエリパラメータのどちらを使用しても違いが出るということです。

• パスパラメータの場合、パラメータはリソースパスの一部です。の場合、そのリソースが見つからなかったために/users/9応答する必要404があります。/users/9リソースであり、結果は単項またはエラーであり、存在しません。これはモナドではありません。
• クエリパラメータの場合、パラメータはリソースパスの一部ではありません。の場合/users?id=9、応答は204リソース/usersが見つかったが、データを返すことができなかったためであるはずです。リソースは/users存在し、結果はn値です。空でも存在します。id一意である場合、これはモナドです。

パスパラメータとクエリパラメータのどちらを使用するかは、ユースケースによって異なります。私は、必須、規範、または識別引数のパスパラメーターと、オプション、非規範、または属性引数（ページング、照合ロケールなど）のクエリパラメーターを好みます。REST APIでは、最初の公開sshキーを取得したり、3番目の住所を取得したりするなど、「子レコード」を取得するためのネストが可能なため、特に使用し/users/9ません。/users?id=9/users/9/ssh-keys/0/users/9/address/2

私は404を使用することを好みます。理由は次のとおりです。

• 単項（1つの結果）およびn-ary（nの結果）メソッドの呼び出しは、正当な理由がない限り変更しないでください。可能であれば、同じ応答コードを使用したいと思います。もちろん、予想される結果の数は違います。たとえば、本体はオブジェクト（単項）またはオブジェクトの配列（n項）であると想定します。
• n-aryの場合、配列を返し、結果がない場合は、セット（ドキュメントなし）を返さず、空のセット（JSONの空の配列またはXMLの空の要素のような空のドキュメント）を返します）。つまり、それはまだ200ですが、レコードはありません。この情報を体内以外にワイヤーに載せる理由はありません。
• 204voidメソッドのようなものです。私はそれを使用しないことGETだけのために、POST、PUT、とDELETE。GET識別子がパスパラメータではなくクエリパラメータである場合、例外を作成します。
• レコードが見つからないのは、クライアントが存在しないIDを使用していることが原因であるNoSuchElementException、ArrayIndexOutOfBoundsExceptionまたはそのようなものです。そのため、クライアントエラーです。
• コードの観点から見ると、取得と204は、回避できるコード内の追加の分岐を意味します。これはクライアントコードを複雑にし、場合によってはサーバーコードも複雑にします（エンティティ/モデルモナドを使用するかプレーンエンティティ/モデルを使用するかによって異なります）。エンティティ/モデルモナドから離れることを強くお勧めします。モナドのうち、操作が成功したと考え、実際に何か他のものを返すべきだったときに200または204を返します。
• クライアントコードは、2xxがサーバーがクライアントの要求したことを実行したことを意味し、4xxがサーバーがクライアントの要求したことを実行せず、それがクライアントの障害である場合、記述および理解が容易になります。クライアントが存在しないIDを要求したため、クライアントがIDで要求したレコードをクライアントに提供しないのはクライアントの責任です。

最後になりましたが、一貫性

• GET /users/9
• PUT /users/9 そして DELETE /users/9

PUT /users/9更新または削除が成功した場合は、DELETE /users/9すでに戻る204必要があります。では、ユーザー9が存在しなかった場合、何を返す必要がありますか？使用するHTTPメソッドに応じて、同じ状況が異なるステータスコードとして表示されることは意味がありません。

その上、規範的ではなく、文化的な理由：プロジェクトで発生する次の事柄にif 204を使用するGET /users/9と、戻り値204がn進法に適していると誰かが思う場合があります。2xxボディをチェックしてからデコードするだけでなく、クライアントはボディをデコードすることを特別にチェックし204てその場合はスキップする必要があるため、クライアントコードが複雑になります。代わりにクライアントは何をしますか？空の配列を作成しますか？では、どうしてそれをネットワークに流さないのですか？クライアントが空の配列を作成する場合、204は愚かな圧縮の形式です。クライアントがnull代わりに使用する場合、まったく異なるワームの缶が開かれます。

Twitterは404を使用し、「データが見つかりません」などのカスタムエラーメッセージを表示します。

参照：https : //developer.twitter.com/en/docs/basics/response-codes.html

204がより適切です。特に、ウェブサイトが安全であることを保証するアラートシステムがある場合、この場合の404アラートは、一部の404アラートがバックエンドエラーまたは通常のリクエストであるにもかかわらず、応答が空であることを知らないため、混乱を招きます。

どちらも適切ではありません。すでに述べたように、たとえば@annebによっても、問題の一部はHTTP応答コードを使用してRESTfulサービスに関連するステータスを転送することに起因していると思います。RESTサービスが独自の処理について述べなければならないことはすべて、REST固有のコードを使用して転送する必要があります。

1

HTTPサーバーが、送信された要求に応答する準備ができているサービスを見つけた場合、HTTP 404で応答するべきではないと主張します。リクエストを処理するサービス。

しばらくの間、次のURLを想定しますhttp://example.com/service/return/test。

• ケースAは、サーバーが「ファイルシステム上のファイルを単に探している」ことです。存在しない場合404は正しいです。ある種のサービスにこのファイルを正確に配信するように依頼し、そのサービスがその名前が何も存在しないことを通知する場合も、同じことが当てはまります。
• ケースBの場合、サーバーは「実際の」ファイルを処理しませんが、実際にはリクエストは他のサービス（ある種のテンプレートシステムなど）によって処理されます。ここでは、サーバーはリソースについて何も知らないので（リソースを処理するサービスから通知されない限り）、リソースの存在について何の主張もできません。

別の動作を明示的に要求するサービスからの応答がない場合、HTTPサーバーは3つのことしか言うことができません。

• 503 リクエストを処理することになっているサービスが実行されていない、または応答していない場合
• 200 それ以外の場合は、HTTPサーバーが実際に要求を満たすことができるため–サービスが後で言う内容に関係なく。
• 400または404、そのようなサービスはなく（「存在するがオフライン」ではない）、他に何も見つからなかったことを示します。

2

手元の質問に戻ると、私は最もクリーンなアプローチは、以前に述べた以外にHTTP応答コードをまったく使用しないことだと思います。サービスが存在して応答している場合、HTTPコードは200になります。応答には、サービスが別のヘッダーで返したステータスが含まれている必要があります。ここでは、サービスは

• REST:EMPTYたとえば、sthを検索するように求められた場合。そしてその研究は空に戻った。
• REST:NOT FOUND特にsthを求められた場合。「IDライク」–ファイル名またはIDやエントリ番号24などのリソースであること–特定のリソースが見つからなかった（通常、1つの特定のリソースが要求され、見つからなかった）
• REST:INVALID 送信されたリクエストの一部がサービスによって認識されない場合。

（これらはHTTP応答コードと同じ値または表現を持っているかもしれませんが、それらは完全に異なるという事実をマークするために、これらに「REST：」をプレフィックスとして付けたことに注意してください）

３

上記のURLに戻って、サービスがこのリクエスト自体を処理しないことをHTTPサーバーに示すが、それをに渡すケースBを調べてみましょうSERVICE。HTTPは、それが引き渡されたものだけを提供し、それが引き渡されSERVICEたreturn/test部分については何も知りませんSERVICE。そのサービスが実行されている場合、HTTP は実際に要求を処理する何かを見つけたのと200同じように戻るはずです。

によって返されるステータスSERVICE（および前述のように、別のヘッダーで確認したいステータス）は、実際に予期されるアクションによって異なります。

• return/test特定のリソースを要求する場合：存在する場合は、ステータスとしてそれを返しREST:FOUNDます。そのリソースが存在しない場合は、を返しREST:NOT FOUNDます。これが拡張されREST:GONEて、一度存在して戻ってこないREST:MOVEDことがわかっていて、ハリウッドがなくなっていることがわかっている場合に戻ることができます。
• return/test検索またはフィルターのような操作と見なされた場合：結果セットが空の場合、要求されたタイプの空のセットとステータスを返しREST:EMPTYます。要求されたタイプとステータスの結果のセットREST:SUCCESS
• return/testによって認識された操作ではない場合SERVICE：REST:ERROR完全に間違っている場合（たとえば、タイプミスなどretrun/test）、またはREST:NOT IMPLEMENTED後で予定されている場合は返します。

4

この区別は、2つの異なるものを混合するよりもはるかに明確です。また、デバッグがより簡単になり、処理が少しでも複雑になります。

• HTTP 404が返された場合、サーバーは「あなたが何について話しているのかわかりません」と私に伝えます。私のリクエストのREST部分はまったく問題ないかもしれませんが、私はすべての間違った場所でpar'Machを探しています。
• 一方、HTTP 200とREST：ERRは、サービスを取得したが、サービスへのリクエストで問題があったことを示しています。
• HTTP 200とREST：EMPTYから、私は何も間違っていないことを知っています-正しいサーバー、サーバーがサービスを見つけ、サービスへの正しいリクエスト-が、検索結果は空です。

概要

この問題と議論は、HTTP応答コードが、結果がHTTPによって提供されるサービスの状態を表すため、またはsthを表すために使用されているという事実から生じます。これは、HTTPサーバー自体のスコープではありません。この不一致のため、質問には答えられず、すべての意見は多くの議論の対象となります。

HTTPサーバーではなくサービスによって処理された要求の状態は、HTTP応答コードによって実際に与えられるべきではありません（RFC 6919）。HTTPコードには、HTTPサーバーが独自のスコープから提供できる情報（つまり、サービスが要求を処理するために検出されたかどうか）のみが含まれる必要があります（SHOULD）。

代わりに、実際に要求を処理しているサービスへの要求の状態についてコンシューマーに伝えるために、別の方法を使用する必要があります（SHOULD）。私の提案は、特定のヘッダーを介してそうすることです。理想的には、ヘッダーの名前とその内容の両方が、消費者がこれらの応答を簡単に処理できるようにする標準に従っています。

RFC7231-page59（https://tools.ietf.org/html/rfc7231#page-59）によると、404ステータスコード応答の定義は次のとおりです。

6.5.4。404見つかりません404（見つかりません）ステータスコードは、オリジンサーバーがターゲットリソースの現在の表現を見つけられなかったか、存在することを開示する意思がないことを示します。404ステータスコードは、この表現の欠如が一時的なものか永続的なものかを示しません。おそらくいくつかの構成可能な手段を通じて、起点サーバーが状態が永続的である可能性が高いことを知っている場合、410（存在しない）状況コードは404よりも優先されます。404応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されていない限り（[RFC7234]のセクション4.2.2を参照）。

そして疑いをもたらす主なものは、上記のコンテキストでのリソースの定義です。同じRFC（7231）によると、リソースの定義は次のとおりです。

リソース：HTTPリクエストのターゲットは「リソース」と呼ばれます。HTTPはリソースの性質を制限しません。リソースとの対話に使用される可能性のあるインターフェースを定義するだけです。[RFC7230]のセクション2.7で説明されているように、各リソースはUniform Resource Identifier（URI）によって識別されます。クライアントがHTTP / 1.1要求メッセージを作成するとき、（[RFC7230]のセクション5.3）で定義されているように、さまざまな形式の1つでターゲットURIを送信します。リクエストが受信されると、サーバーはターゲットリソースの有効なリクエストURIを再構築します（[RFC7230]のセクション5.5）。HTTPの設計目標の1つは、リソースの識別を要求のセマンティクスから分離することです。これは、要求のセマンティクスを要求メソッド（セクション4）といくつかの要求変更ヘッダーフィールド（セクション5）に付与することで可能になります。

したがって、私の理解では、404ステータスコードは、空の結果を伴う成功したGETリクエストでは使用しないでください（例：特定のフィルターの結果がないリスト）

そのようなことは主観的である可能性があり、両側にはいくつかの興味深いさまざまな確固たる議論があります。ただし、（私の意見では）欠落データに対して404を返すことは正しくありません。これを明確にするための簡単な説明を次に示します。

• リクエスト：データをいただけますか？
• リソース（APIエンドポイント）：そのリクエストを受け取ります。ここで[潜在的なデータの応答を送信します]

何も壊れず、エンドポイントが見つかり、テーブルと列が見つかったので、DBが照会され、データが「正常に」返されました。

ここで、「成功した応答」にデータがあるかどうかは関係なく、「潜在的な」データの応答を要求し、「潜在的な」データを含む応答は実行されました。null、空などは有効なデータです。

200は、要求が成功したことを意味します。私はデータを要求していますが、HTTP / RESTには何も問題がありませんでした。データ（空であるにもかかわらず）が返されたので、「データの要求」は成功しました。

200を返し、特定のシナリオごとに、要求者が空のデータを処理できるようにします。

この例を考えてみましょう：

• リクエスト：ユーザーID 1234で「違反」テーブルをクエリする
• リソース（APIエンドポイント）：応答を返しますが、データは空です

空のこのデータは完全に有効です。これは、ユーザーに違反がないことを意味します。これはすべて有効な200です。

違反はありません、ブルーベリーのマフィンがあります！

これを404と見なした場合、何を述べますか？ユーザーの違反は見つかりませんでしたか？今、文法的には正しいですが、RESTの世界ではそれは正しくありません。成功か失敗かはリクエストに関するものです。このユーザーの「違反」データは正常に検出されました。違反はゼロです-有効な状態を表す実数。

[チキーノート..]

タイトルでは、無意識のうちに200が正しい応答であることに同意しています。

有効なリクエストで空のデータに適切なREST応答コードは何ですか？

主観やトリッキーな選択に関係なく、使用するステータスコードを選択する際に考慮すべき点をいくつか次に示します。

1. 一貫性。「データなし」に404を使用する場合は、応答がデータを返さないたびに使用します。
2. 同じステータスを複数の意味で使用しないでください。リソースが見つからなかったときに404を返す場合（APIエンドポイントが存在しないなど）、返されたデータがない場合はそれを使用しないでください。これは単に応答への対応を困難にします。
3. コンテキストを注意深く検討してください。「リクエスト」とは何ですか？達成しようとしていることは何ですか？

応答コンテンツを共通の列挙型でエンコードします。これにより、クライアントはスイッチをオンにして、それに応じてロジックをフォークできます。「データが見つかりません」404と「Webリソースが見つかりません」404の違いをクライアントがどのように区別するのかわかりませんか？誰かがユーザーZ / 9 を参照して、リクエストが有効であるにもかかわらずデータが返されなかったかのようにクライアントに疑問を抱かせたくない場合。

410を使用しないのはなぜですか？これは、リクエストされたリソースが存在しないことを示唆しており、お客様の場合、クライアントはそのリソースをリクエストしないことが予想されますusers/9。

410の詳細については、https：//www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlをご覧ください。

とてもシンプルで明確なものがこのスレッドで「意見ベース」になったのは悲しいことです。

HTTPサーバーは、静的なWebページ、検索結果のリスト、他のエンティティのリスト、何かのjson記述、メディアファイルなど、コンテンツの抽象化である「エンティティ」のみを認識します。

このような各エンティティは、一意のURLで識別できることが期待されています。

• / user / 9-単一のエンティティ：USER ID = 9
• / users-単一のエンティティ：すべてのユーザーのリスト
• /media/x.mp3-単一のエンティティ：x.mp3と呼ばれるメディアFILE
• / search-単一のエンティティ：クエリパラメータに基づく動的なコンテンツ

サーバーが指定されたURLでリソースを見つけた場合、その内容が何であるかは関係ありません-2Gのデータ、null、{}、[]-存在する限り、200になります。サーバーに認識されていないため、404「見つかりません」を返すことが期待されています。

1つの混乱は、アプリケーションに特定のパス形状のハンドラーがある場合、エラーであってはならないと考える開発者からのようです。HTTPプロトコルの観点からは、サーバーに一致するエンティティが存在しない限り、サーバーの内部で何が起こったか（つまり、デフォルトルーターが応答したか、特定のパス形状のハンドラーであったか）は関係ありません。リクエストされたURL（MP3ファイル、ウェブページ、ユーザーオブジェクトなどをリクエスト）。有効なコンテンツ（空またはその他）を返すため、404（または410など）である必要があります。

もう1つの混乱のポイントは、「データなし」と「エンティティなし」にあるようです。前者はエンティティの内容に関するものであり、後者はその存在に関するものです。

例1：

• データなし：/ usersは200 OKを返します。本文：[]誰もまだ登録していないため
• エンティティーなし：パス/ usersがないため、/ usersは404を返します

例2：

• データなし：/ user / 9は200 OKを返し、本文：{}、ユーザーID = 9が個人データを入力したことがないため
• エンティティなし：ユーザーID = 9がないため、/ user / 9は404を返します

例3：

• データなし：/ search？name = Joeは200 OK []を返します。これは、DBにJoeがないためです。
• エンティティなし：/ search？name = Joeは、パス/ searchがないため404を返します

応答するデータがないという理由だけで戻る場合、404はどのクライアントにとっても非常に混乱します。

私にとって、ボディが空のResponse Code 200は、すべてが完璧であることを理解するには十分ですが、要件に一致するデータはありません。

Microsoftによると、ASP.NET Core Web APIのコントローラーアクションの戻り値の型で、ほぼ下までスクロールすると、データベースにないオブジェクトに関連する404に関する次の言い回しが見つかります。ここでは、404が空のデータに適していることを示唆しています。

多くの人が述べたように、404は誤解を招くものであり、リクエストURIが存在しない場合、またはリクエストされたURIがリクエストされたリソースをフェッチできない場合、クライアントはそれを区別できません。

200ステータスにはリソースデータが含まれることが予想されるため、適切な選択ではありません。204ステータスは完全に別の意味を持ち、GETリクエストの応答として使用すべきではありません。

他のすべての既存のステータスは、何らかの理由で該当しません。

このトピックが何度も何度も議論されているのを見てきました。私にとって、このトピックに関する混乱を解消するには、専用の成功ステータスが必要であることは明らかです。「209-表示するリソースがありません」のようなもの。

IDが見つからないことはクライアントエラーと見なされないため、2xxステータスになります（クライアントがサーバーのDBにあるすべてを知っている場合、サーバーに何も尋ねる必要はありませんね）。この専用ステータスは、他のステータスの使用で議論されたすべての問題に対処します。

唯一の質問は、RFCでこれを標準として受け入れるにはどうすればよいですか。