get
をapi/users
に呼び出してユーザーのリストを取得したいとしますが、現在テーブルは切り捨てられているため、ユーザーはいません。このシナリオ404
または204
に対する適切な対応は何ですか?
どちらとも言えません。
404ステータスコードは、リソースが見つからない状況のために予約する必要があります。この場合、リソースはユーザーのコレクションです。このコレクションは存在しますが、現在は空です。個人的には、誰かが偶然数人のユーザーを削除したからといって、ある日200
と翌日404
を受け取った場合、アプリケーションのクライアントの作成者として非常に混乱するでしょう。私はどうしたらいいですか?私のURLは間違っていますか?誰かがAPIを変更し、リダイレクトを残すことを怠ったか。
w3cによる204ステータスコードの説明 からの抜粋を次に示します。
サーバーは要求を実行しましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。
この場合、これは理にかなっているように見えるかもしれませんが、クライアントを混乱させると思います。 204
は、一部の操作が正常に実行され、データを返す必要がないことを示すことになっています。これは、DELETE
リクエストへの応答として、またはデータを返す必要のないスクリプトを起動するのに最適です。 api/users
の場合、通常、ユーザーのコレクションの表現を受け取ることを期待します。応答本文を1回送信し、もう1回送信しないと、一貫性がなくなり、誤解を招く可能性があります。
上記の理由(一貫性)のために、空のコレクションの表現を返します。 XMLを使用していると仮定しましょう。空でないユーザーのコレクションの通常の応答本文は次のようになります。
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
リストが空の場合、次のように応答できます(200
を使用したまま)。
<users/>
いずれにせよ、クライアントは特定のよく知られた形式に従う応答本文を受け取ります。不要な混乱やステータスコードのチェックはありません。また、ステータスコードの定義に違反することもありません。みんな幸せです。
JSON、HTML、または使用しているどの形式でも同じことができます。
実行時の状況に応じて、2つのコードのいずれかに答えます。
404(見つかりません)
テーブルがない場合、この答えはかなり正しいです。空のテーブルだけでなく、ユーザーテーブルもありません。正確なアイデアを確認します-リソースなし。さらなるオプションは、テーブルが存在しない理由をより詳細に提供することです。さらに詳細なコードがいくつかありますが、404は、テーブルが実際にない状況を参照するのに適しています。
200(OK)
テーブルはあるが空であるか、リクエストプロセッサがすべての結果を除外するすべてのケース。これは、「あなたのリクエストは正しい、すべては問題ありませんが、データがないか、リクエストに一致するデータがないという理由だけでデータに一致しません」という意味です。これは、セキュリティ拒否の回答とは異なる必要があります。また、いくつかのデータがあり、一般にテーブルにアクセスすることはできますが、リクエストに一致するすべてのデータにはアクセスできない状況で200を返すことを投票します(データはオブジェクトレベルのセキュリティのために除外されましたが、一般的には要求)。
ユーザーオブジェクトのリストを期待している場合、最良の解決策は、404または204応答を使用するよりも200 OKで空のリスト([])を返すことです。
200 OKリストが空の場合。
理由:空のテーブルは、テーブルは存在するがレコードがないことを意味します。
404 Not Foundは、要求されたエンドポイントが存在しないことを意味します。