web-dev-qa-db-ja.com

HTTP GETリクエストステータス204対404

ユーザーとアルバムの2つのリソースがあります。ユーザーにはアルバムのリストがあります。アルバムを取得するには、2 REST API。

  1. user/{userId}/albums/{albumId}見つからない場合はalbumIdでアルバムを取得します404を返します
  2. user/{userId}/albumsはuserIdですべてのアルバムを取得します。この場合、ユーザーがアルバムを持っていない場合、ステータスコード204または404は何ですか？
resthttp-status-code-404httpresponse
13
Navrattan Yadav

アルバムがないことが本当にエラーと見なされていますか？アルバムがJSON配列として返されると仮定すると、このような状況に対する一般的な応答は、本体として空の配列を持つHTTP 200です。

404を返すと、リソースが存在しないことを示します。つまり、この特定のユーザーのアルバムのリストを要求することはpossibleでもないということです。しかし、実際には、アルバムのリストを正常に返すことができます。リストが空であることだけです。それは私にはまったく例外的ではないようです。これは、（他のエンドポイントを使用して）存在しないIDを使用して特定のアルバムを取得することとはまったく対照的です。このような状況では、404が正しいです。

204は404よりも優れているように見えますが、少なくとも要求は成功したがコンテンツがなかったことをクライアントに伝えるため、「不在の成功」を示すために実際に使用することは意図されていません。むしろ、リソースは存在するが、何らかの理由でサーバーが応答本文にリソースを含めないことを選択したことを通知します。たとえば、リクエストの目的は単にヘッダーをクライアントに返すことでした。

204は、POSTリクエストが新しいリソースを作成せずにサーバーによって実行された場合（201 CREATEDを暗示する）またはリソースを返すことに関係のない他の何らかの理由で。

あなたが必要なのは

GET /user/xxx/albums

HTTP/1.1 200 OK

[]
25
JHH

エラーコード404

Webサイトホスティングサーバーは通常、ユーザーが壊れたリンクまたはデッドリンクをたどろうとすると、「404 Not Found」Webページを生成します。

戻りコード204

サーバーは要求を実行しましたが、エンティティ本体を返す必要はありません。

結論

明らかに、204エラーを発生させる必要があります。 404を使用すると、ユーザーが邪魔される可能性があります。さらに、対象のアルバムが存在しない場合は404を使用します。 1と2の両方に404を使用するには、ロジックが不足しています。

9
Saphirel

HTTPプロトコルを定義する RFC2616 がステータスコードについて述べていることは次のとおりです。

ステータスコードの最初の桁は、応答のクラスを定義します。最後の2桁には分類の役割はありません。最初の桁には5つの値があります。

  - 1xx: Informational - Request received, continuing process

  - 2xx: Success - The action was successfully received,
    understood, and accepted

  - 3xx: Redirection - Further action must be taken in order to
    complete the request

  - 4xx: Client Error - The request contains bad syntax or cannot
    be fulfilled

  - 5xx: Server Error - The server failed to fulfill an apparently
    valid request

あなたの場合、リクエストは成功しましたが、表示するアルバムがないため、2xxカテゴリのステータスを使用する必要があります。

RFCは204ステータスについて次のように述べています。

10.2.5 204コンテンツなし

サーバーは要求を実行しましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。応答には、エンティティヘッダーの形式で新規または更新されたメタ情報が含まれる場合があります。これは、存在する場合、要求されたバリアントに関連付けられる必要があります。

クライアントがユーザーエージェントである場合、リクエストの送信を引き起こしたものからドキュメントビューを変更すべきではありません。この応答は、ユーザーエージェントのアクティブなドキュメントビューを変更せずにアクションの入力を許可することを主な目的としていますが、新規または更新されたメタ情報は、ユーザーエージェントのアクティブなビューに現在あるドキュメントに適用される必要があります。

204応答にはメッセージ本文を含めてはならない（MUST NOT）ため、ヘッダーフィールドの後の最初の空行で常に終了します。

RFCでは、204は主に入力を許可することを目的としているため、これを使用しないでください。この場合は200を使用します。

8
Jefferson Lima