HTTP Get with 204 No Content：それは正常ですか
HTTP GET Requestがステータスコード204 - No Content？同様に、これはHTTP GETが達成すべきことに関して意味的に正しいですか？ 204 - No ContentはokayHTTP POST Requestの場合。GET要求の場合、ない場合データを返送する場合、204ステータスコードは適切ですか？404を使用する必要がありますか、または成功のために200のままにして空の応答が必要ですか？
ユースケースは、この質問のJava Google App Engine用に作成しているアプリケーションです。サーブレットにリクエストを送信していますが、送信するデータはクライアントへの返信は、HTTPレスポンスではなくチャンネルAPIソケットを介して送信されます。現在、クライアントはPOSTをリクエストボディにコンテンツなしで送信し、204レスポンスを待ちます。 Channel APIソケットをポーリングする前にサーブレットからリクエストの本文にデータが送信されていないため、POSTではなくGETを送信する方が理にかなっているかどうかを議論しています。
204コンテンツなし
サーバーは要求を実行しましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。応答には、エンティティヘッダーの形式で新しいメタデータまたは更新されたメタ情報が含まれている場合があります。
ステータスコード204のRFC部分 によると、GET要求の有効な選択肢のようです。
404 Not Found、200 OK空のボディと204 No Contentは完全に異なる意味を持ち、時には適切なステータスコードを使用できない場合がありますが、ルールを曲げると、1日またはそれ以降にあなたに噛み付くように戻ります 。したがって、適切なステータスコードを使用できる場合は、それを使用してください！
GETまたはPOSTはどちらも仕事をするので非常に個人的ですが、GETではなくPOSTを維持することをお勧めします、2つの理由：
- 他の部分（私が正しく理解している場合はサーブレット）は、データを取得しないアクションを実行する必要があります。
- URLにパラメータが存在しない場合、デフォルトでGETリクエストはキャッシュ可能です。POSTはそうではありません。
現在のPOSTとHTTP 204応答の組み合わせは問題ありません。
POSTをGETの普遍的な代替として使用することは、RFCではサポートされていません。それぞれに固有の目的とセマンティクスがあります。
GETの目的は、リソースを取得することです。したがって、許可されていても、HTTP 204はコンテンツIS応答で予期されます。 HTTP 404 Not Found または HTTP 410 Gone は、サーバーが要求されたリソースを提供できなかった場合に適した選択肢です。
RFCは、PUT、POSTおよびDELETEの適切な応答としてHTTP 204を具体的に呼び出しますが、GETの場合は省略します。
GETのセマンティクスについてはRFC を参照してください。
返される可能性のある他の応答コードがあり、コンテンツがないことを示し、HTTP 204よりも適切です。
たとえば、条件付きGETの場合、本文コンテンツを含まない HTTP 304 Not Modified 応答を受信できます。
GET/204は、既知の固定長の定位置配列であるが穴のあるRESTfulコレクションで使用します。
GET /items
200: ["a", "b", null]
GET /items/0
200: "a"
GET /items/1
200: "b"
GET /items/2
204:
GET /items/3
404: Not Found
204を使用したPOST/GETは、一見問題なく見えるようで、動作します。
ドキュメントには、2xx-このクラスのステータスコードは、クライアントが要求したアクションが正常に受信され、理解され、受け入れられ、処理されたことを示しています。一方、4xx-ステータスコードの4xxクラスは、クライアントが誤っていると思われる状況を対象としています。
リクエストがサーバーで正常に受信、理解、処理されたため。その結果、リソースが見つかりませんでした。したがって、この場合、これはクライアント側のエラーではなかったか、クライアントがエラーを起こしていません。
したがって、これは4xxではなく、シリーズ2xxコードである必要があります。この場合の204（コンテンツなし）の送信は、404または410の応答よりも優れています。