[519] 204
(No Content) は、処理が成功したことと、 payload body
が無いことを表す状態符号です。
[513] 204
は、鯖が要求を成功裏に満足し、
応答の payload body に入れて送信する追加情報はないことを示します。 >>512
[514] 応答ヘッダーのメタデータは対象資源と、 要求された動作の適用後の選択された表現についてのものです。 >>512
[206] 204
応答は、メッセージ本体を持ちません >>205。
ヘッダーの後の最初の改行でメッセージが終わります >>12。
[511] 起源鯖は、対象資源が現在表現を持っており、 PUT
によりその編集に成功した場合には、 200
か 204
を送信しなければなりません >>507。
[218] 起源鯖は、処理が成功した場合には、
処理が成功するであろうものの実施されていない場合には 202
を、
実施され追加情報は特に無い場合には 204
を、
実施され応答メッセージに状態を説明する表現を含める場合には 200
を返すべきです >>215。
[6] COPY
要求 >>5 や MOVE
要求 >>8 によって既存の終点資源が上書きされた場合には、
204
応答を返します。
[7] DELETE
要求に対する 207
応答内の status
要素では使うべきではありません
>>4。
[10] ULOCK
要求が成功した場合、
204
応答を返すことができます。
200
より 204
が適切です。 >>9
[516] 利用者エージェントは利用者に適当な方法で成功を示し、 また新規や更新されたメタデータが含まれていれば (利用者エージェントが保持しているキャッシュなどの) 表現にも適用することが期待されています >>512。
[1] 駄目駄目な UA は、 204 が返っても読み込み中のままになったりします。
また、例えばボタンの押下によって利用者が画面表示上の変化を期待していそうな場合なんかは、 表示に変化が起こらないとすると利用者が戸惑って何度も押してしまったりするかもしれません。
その辺、資源の著者や UA の作者の配慮でうまく問題を回避して欲しいです。。。
[2] >>1 最低でも、 UA は読み込みを終了して、状態棒にサーバーが要求を受け入れましたみたいなメッセージを出して欲しいですね。
[208] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) http://tools.ietf.org/html/rfc7252#section-5.9.1.4
[520] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.3
[13] head :no_content (204 status code) returns error · Issue #510 · Alamofire/Alamofire ( ()) https://github.com/Alamofire/Alamofire/issues/510
[14] RFC 7967 - Constrained Application Protocol (CoAP) Option for No Server Response () https://tools.ietf.org/html/rfc7967
[15] RFC 7967 - Constrained Application Protocol (CoAP) Option for No Server Response () https://tools.ietf.org/html/rfc7967#section-3.4
[16] Under-specified: parsing behavior following 204 response · Issue #26 · httpwg/http11bis () https://github.com/httpwg/http11bis/issues/26
[17] 201
のような意味で 204
を使うサーバーがあり、
Location:
に作成された資源の URL
を設定するようです。