HTTPステータスコード：204 OR 200本文に空のオブジェクトが含まれていますか？
204 HTTPステータスコードの使用例を理解できません。 RFC2616は言う：
10.2.5 204コンテンツなし
サーバーは要求を満たしましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。の
応答には、新しいまたは更新されたメタ情報が
エンティティヘッダー。存在する場合、
リクエストされたバリアント。クライアントがユーザーエージェントである場合、そのクライアントは、ドキュメントビューを、リクエストが送信された原因から変更するべきではありません。この応答は主に、ユーザーエージェントのアクティブなドキュメントビューに変更を加えずにアクションの入力を可能にすることを目的としていますが、新しいまたは更新されたメタ情報は現在ユーザーエージェントのアクティブなビューにあるドキュメントに適用する必要があります。
204応答にはメッセージ本文を含めてはならないため、常にヘッダーフィールドの後の最初の空行で終了します。
「ドキュメントビュー」はDOMを指しますか？
たとえば、AJAXユーザーを削除するリクエストを発行し、リクエストが正常に完了したら、ページを更新してリストからユーザーを削除する場合、サーバーが{ }レスポンスまたはボディなしの204として？
編集：私の主な関心事は、「クライアントがユーザーエージェントの場合、リクエストが送信される原因となったものからドキュメントビューを変更すべきではない」ことです。部。自分の言葉で再定式化するには：204を返す場合にDOMを更新できますか？
「ドキュメントビュー」はDOMを指しますか？
正確には、レンダリングされたドキュメントを意味します。 DOMはレンダリングされたドキュメントの表現ではありません。ドキュメントツリーの抽象モデルです。各UAは異なるレンダリングを行う場合があります。
AJAXユーザーを削除するリクエストを発行し、サーバーが応答として{}を含む200を提供した場合、リクエストが正常に完了したら、ページを更新してリストからユーザーを削除しますまたは体のない204？
これは、APIとその「適合性」に依存します。したがって、「DELETE」動詞（つまり、RESTful API）を使用して削除要求を送信した場合、応答は200 OKになります。ただし、APIが特に重要な場合は、204を送信することもできます。
'/ some/view？id = 1＆action = delete'にGETリクエストを送信しているだけの場合、ほとんどの場合 200 OKが返されます
どちらの場合も、2番目の部分のために、DOMを自由に変更することができます（したがって、ドキュメントの再レンダリングをトリガーします）。
ただし、新規または更新されたメタ情報は、現在ユーザーエージェントのアクティブビューにあるドキュメントに適用する必要があります（SHOULD）。
したがって、 <strike>
どちらも実際には有効です。それはすべてあなたのアプリケーションに依存します。
有効な削除では、200または204の両方の応答コードが返されます。
確かに、ドキュメントビューはDOMを参照しています。
この質問 はそれについて話します。