有効なリクエストだがデータが空の場合の適切な REST 応答コードは何ですか? 質問する

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

リクエストは受信され、適切に処理されました。サーバー上のアプリケーション コードはトリガーされましたが、クライアント側では間違いは発生していない可能性があります。そのため、クライアント エラー コードの全クラス (4xx) が適切ではない可能性があります。

さらに重要なのは、404 はさまざまな技術的な理由で発生する可能性があることです。たとえば、アプリケーションがサーバー上で一時的に非アクティブ化またはアンインストールされている、プロキシ接続の問題などです。

確かに、このような場合のために 5xx エラー クラスは存在しますが、実際には、影響を受けるミドルウェア コンポーネントには、エラーが自分側にあることを知る方法がなく、エラーがクライアント側にあると想定して、500/503 ではなく 404 で応答することがよくあります。

したがって、ステータス コードだけに基づいて、クライアントは「探しているものが存在しない」ことを意味する 404 と「重大な問題が発生しているため、このエラーを運用チームに報告してください」を意味する 404 を区別できません。

これは致命的になる可能性があります。あなたの会社で、年間ボーナスが支払われる従業員全員をリストする会計サービスがあるとします。残念ながら、このサービスが呼び出された 1 回だけ 404 が返されます。これは、ボーナスが支払われる従業員がいないことを意味するのでしょうか、それとも、アプリケーションが現在新しいデプロイメントのためにダウンしていて、404 は実際にはアプリケーション自体からではなく、インストール先の Tomcat から返されていることを意味するのでしょうか。この 2 つのシナリオは同じステータス コードを生成しますが、その意味は根本的に異なります。

-> 要求されたリソースが一時的にアクセスできないのではなく、確実に存在しないことを認識する必要があるアプリケーションの場合、応答エンティティのない 404 はほとんど使用できません。

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

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

それでも、私は空の応答の 204 または 200 を好みます。 こうすることで、要求の技術的な実行のステータスが要求の論理的な結果から分離されます。 2xx は「技術的な実行は OK、これが結果です、対処してください」という意味です。

ほとんどの場合、空の結果が許容されるかどうかの判断はクライアントに任せるべきだと思います。技術的に正しく実行されているにもかかわらず、応答エンティティなしで 404 を返すと、クライアントは、単にエラーではないケースをエラーと見なす可能性があります。

別の観点: 運用の観点から、404 は問題となる可能性があります。これは、有効なサービス応答ではなく、接続性/ミドルウェアの問題を示している可能性があるため、調査して修正する必要がある真の技術的問題 (たとえば、リクエスト ルーティングのどこかにあるプロキシの設定ミス) を隠す可能性がある、メトリック/ダッシュボード内の「有効な」404 の数が変動することは望ましくありません。一部の API では、401/403 の代わりに 404 を使用して (たとえば、gitlab はそうします)、リクエスト URI は有効であるが、リクエストにはアクセスする権限がないという情報を隠すことで、この問題がさらに悪化します。この場合も、404 は、有効な「リソースが見つからない」結果としてではなく、技術的なエラーとして扱う必要があります。

編集: わあ、これは大きな論争を引き起こしましたね。404 に対する別の反論があります。厳密に HTTP 仕様 (RFC7231) の観点から見ると、404 はリソースが存在しないことを意味するわけではありません。サーバーに要求されたリソースの現在の表現がなく、一時的なものである可能性があることを意味します。したがって、厳密に HTTP 仕様によると、404 は要求されたものが存在しないという点に関して本質的に信頼できません。要求されたものが確実に存在しないことを伝えたい場合は、404 を使用しないでください。

覚えておいてください。リソースはあなたが望むものなら何でも構いません。HTTP 仕様では、それを明示的にあなたに任せています。それは、あなたが調べることができ、空である可能性のあるバケットである可能性があります (バケットは見つかりましたが、空です、http 204)。それは、クライアントがそのリクエストを送信したことが有効であると考えるかどうかに帰着します。404 がクライアント エラーであるということは、クライアントがそもそもそのリクエストを送信すべきではなかったことを意味します。クライアントが URL を「調査」しても問題ない場合は、リソースを空である可能性のあるバケットのように扱い、204 を返します。空の応答がリクエストが送信されるべきではなかったことを示している場合は、404 を使用してそれを監視します。ミドルウェアが挿入した偽の 404 は害を及ぼさず、監視を正当にトリガーします。