空のテーブルに対する適切なREST応答?


106

を呼び出しGETてユーザーのリストを取得したいとしますapi/usersが、現時点ではテーブルが切り捨てられているため、ユーザーはいないとします。このシナリオの適切な応答は何ですか:404または204


19
私は200と空のコレクションで応答します(空の応答本文ではなく、要素のないコレクションです。これは返される形式によって異なります)
toniedzwiedz

4
このコンテキストでの404は、おそらく「テーブルが見つかりません」に適しています。空のリストを返すと思います。
マタ


2
@EJoshuaSではありません。どちらの質問も私の質問です。それらは類似していますが、重複していません。
IMB

1
@EJoshuaSそれらは明らかに重複ではありません。この質問は/api/users、その質問について/api/users/1です。
フランクリンユー

回答:


231

どちらとも言えません。

なぜ404(見つかりません)ではないのですか?

404ステータスコードは、リソースが見つからない場合のために予約する必要があります。この場合、リソースはユーザーのコレクションです。このコレクションは存在しますが、現在は空です。個人的には、誰かがたまたま数人のユーザーを削除しただけで200404ある日と次の日があった場合、アプリケーションのクライアントの作成者として非常に混乱します。私はどうしたらいいですか?私のURLは間違っていますか?誰かがAPIを変更し、リダイレクトを残すことを怠っていましたか?

なぜ204(コンテンツなし)ではないのですか?

これはw3cによる204ステータスコードの説明から抜粋です

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

この場合、これは妥当に思えるかもしれませんが、クライアントを混乱させることにもなると思います。A 204は、一部の操作が正常に実行され、データを返す必要がないことを示しています。これは、DELETEリクエストへの応答として、またはおそらくデータを返す必要のないスクリプトを起動するのに最適です。の場合api/users、通常はユーザーのコレクションの表現を受け取ることを期待しています。応答本文を1回送信し、それをもう1回送信しないと、一貫性がなく、誤解を招く可能性があります。

200を使用する理由(OK)

上記の理由(一貫性)のため、空のコレクションの表現を返します。XMLを使用しているとしましょう。空でないユーザーのコレクションに対する通常の応答本文は、次のようになります。

<users>
  <user>
    <id>1</id>
    <name>Tom</name>
  </user>
  <user>
    <id>2</id>
    <name>IMB</name>
  </user>
</users>

リストが空の場合は、次のようなもので応答できます(まだを使用します200)。

<users/>

どちらの方法でも、クライアントは特定のよく知られた形式に従う応答本文を受け取ります。不要な混乱やステータスコードのチェックはありません。また、ステータスコードの定義に違反していません。みんな幸せです。

JSON、HTML、または使用している任意の形式でも同じことができます。


4
間違いなく同意します。RESTの場合は、ステータスコード200と空の配列を返すだけです[]
チャドジョンソン

理にかなっています。難しくする必要はありません。404は混乱を招くでしょう。
Witold Kaczurba

エンドポイントで、あなたのポケットにコインを記述するAPIとさせて頂きます:GET /singleCoin-あなたのポケットから戻っランダムな単一のコインを、GET /severalCoins-あなたのポケットからいくつかの硬貨は、あなたが一度につかむことができ返します。現在、ポケットにコインがないとします。あなたが頼むときあなたGET /singleCoinは得るでしょう404 Not Found、しかしあなたが頼むときあなたは空のリストでGET /severalCoins得るでしょう。一つの事実-あなたはコインを持っていません、異なる応答で説明されています、なぜですか?ポケットにはコインが入っていないので、いつでも入手した方がいいと思います。200 OK[]404 Not Found
センパシャ

1
@sempashaそれはあなたが何を意味するかによりますGET /severalCoins。あなたはそれが義務付け場合GET /severalCoins しなければならないいくつかのコインを返し、それはOKではないので、それは200であってはなりません。サーバーはクライアントが望むものを提供できませんでした。以下のために/singleCoin、クライアントは劣らず、これ以上、正確に一つのコインをしたいので、これは明らかではありません。これはでも同じです/coins/7/coinsエンドポイントとは対照的に、通常、クライアントはコインなし、1枚または複数のコインを期待します。それらはすべて有効な応答です。コインがない場合、これは彼らが望んでいることです。List<Coin>代わりに、Javaのemplyのようなものですnull
フランクリン・ユー

15

実行時の状況に応じて、次の2つのコードのいずれかに答えます。

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

テーブルがない場合、この答えはかなり正しいです。空のテーブルだけでなく、ユーザーテーブルもありません。それは正確なアイデアを確認します-リソースはありません。その他のオプションは、テーブルがない理由の詳細を提供することです。詳細なコードがいくつかありますが、404は、実際にテーブルがない状況を参照するのに非常に適しています。

200(OK)

テーブルはあるが空であるか、リクエストプロセッサがすべての結果を除外したすべてのケース。これは、「リクエストは正しいですが、すべてが大丈夫ですが、データがないか、リクエストに一致するデータがないために、データが一致しません。これは、セキュリティ拒否の回答とは異なる必要があります。私はまた、いくつかのデータがあり、一般にテーブルへのアクセスは許可されているが、リクエストに一致するすべてのデータへのアクセスは許可されていない状況で200を返すように投票します(データはオブジェクトレベルのセキュリティのために除外されましたが、一般的には許可されていますリクエスト)。


10

ユーザーオブジェクトのリストが必要な場合、最善の解決策は、404または204応答を使用するよりも、200 OKで空のリスト([])を返すことです。


2

間違いなく200を返します。

404は、リソースが見つからないことを意味します。しかし、リソースは存在します。また、応答のステータスが404の場合。ユーザーリストが空または入力済みであることをどのようにして知ることができますか?


  • '/ users'が空の場合は '200'を返します。
  • '/ users / 1'(IDが見つからない場合)。404を返す必要があります。

2

空のリストで200 OKでなければなりません。

理由:テーブルが空の場合、テーブルは存在しますがレコードがありません。

404 Not Foundは、リクエストされたエンドポイントが存在しないことを意味します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.