HTTP APIは常に本体を返す必要がありますか？
HTTP API応答に関する何らかの基準はありますか？
この談話スレッド を読んだ後、私は不思議に思い始めました。私の仕事ではパブリックHTTP JSON APIを開発しており、厳密に必要でない場合は何も返しません（たとえば、/ resource/{id}へのPUTは、OKまたは対応する4XXまたは5XXコードの場合にのみ200を返しますが、 JSON本文）
ジェネリック{"success":true}上記のリンクについて説明したように、または「ボイド」ボディを返し、http応答コードですべてを処理しても問題ありませんか？
PUTについて、ただしPOSTにも適用されます。 HTTP仕様 セクション9は、次のようなシナリオになると、ルールまたはアドバイス（SHOULD）については少し空白です。あなたの質問に関連する行は、最も密接にカバーされています：
新しいリソースが作成される場合、Originサーバーは201（Created）応答を介してユーザーエージェントに通知する必要があります。既存のリソースが変更された場合、200（OK）または204（No Content）応答コードのいずれかを送信して、リクエストが正常に完了したことを示す必要があります。
私はそれ以上の睡眠を失うとは思いませんが、JSONのチャンクを応答に追加することで何が得られますか？あなたはちょうどバルクアウトしました（OK、バルクはやり過ぎかもしれません！）ステータスコードがすでに伝えているはずだったものをより正確に繰り返さないレスポンスです。 PUTによって新しいオブジェクトが返された場合（PUTの意図と同様）、オブジェクトを更新した場合は204が返されます。
ちなみに、APIは200ではなく、何も返されない場合は204を使用します。
RESTfulインターフェースのセットを開発していると仮定すると、それ自体標準はありません。そのため、何をするにせよ、それを文書化し、例を提供すれば、すべてが大丈夫です。
基本HTTP標準では、応答とともに返されるドキュメントの存在を義務付けていません。経済のために、HTTPステータスが必要なすべてを伝える場合、ボディは無駄になります。ただし、新しいルールを追加するHTTPの上に構築された標準があります。
以下を指定するオープンな JSON API標準 があります。
- JSONオブジェクト[〜＃〜] [〜＃〜]はすべてのJSON APIのルートにある必要がありますresponse 資料。 （斜体は、テキストを明確にするために追加したものを表します）
残念ながら、標準は空のドキュメントを表す方法を指定していません。これは進行中の作業です。せいぜいガイドラインとして使用します。
一部のアプリケーション（ ElasticSearch など）は完全なJSON APIを提供し、常にいくつかのメタデータを持っているため、サーバーがデータを管理する方法をよりよく理解できます。標準の応答オブジェクトは、インデックスの状態、リクエストがエラーになった場合、影響を受けたノードの数などを通知します。ElasticSearchはMIMEタイプに「application/json」を使用するため、ガイドラインを適用している可能性は低いですjsonapi.org標準。
JQueryおよび同様のJavaScriptフレームワークは、常にドキュメントが存在することを前提としています。問題は、APIコンシューマーにどの程度のエラーチェックを強制したいかです。リクエストのタイプに基づいてのみ拡張されるすべてのレスポンスの標準フォーマットを思いついた場合、リターンドキュメントの必要性を満たし、APIコンシューマーによるデバッグを容易にすることができます。
Noたとえば、204応答の場合、メッセージ本文を含めることはできません。 {success | status | isSuccessful：true}は冗長です。
実際には（またはjqueryの以降のバージョンで言うべきでしょう）、application/jsonコンテンツタイプの空の応答はエラーを発生させます。私は、それがapplication/jsonであるため、有効なjson本体が必要であるという主張を理解しています。したがって、application/jsonコンテンツタイプの空の応答は、有効なjsonである「null」または「{}」になります。
空の応答に対してapplication/jsonを返さない、jqueryで機能する別の方法があります。 text/plainなどを使用して、クライアントがそのタイプを処理できることを確認してください。
注メッセージ本文を返すことを明示的に禁止するために、私は204しか覚えていません。私たちが見つけたのは、常に204を使用できるわけではないということです。問題は、204応答のMSIEドロップ応答ヘッダーであるため、コンテンツおよびヘッダーがありません。悪いです。多くのユーザーがMSIEを使用しているため、ステータスを200に変更する必要がありました。
いいえ、しかしそれはあなたのコードの一貫性のために役立ちます。また、デバッグ目的にも適しています。また、ウェブサイトのメンテナンスにも役立ちます。これを覚えておいてください：エラーコードはマシン用、エラーメッセージは人間用です。したがって、レスポンスボディを使用することをお勧めします。とにかく、そのマイナスの影響は、その利点と比較してごくわずかです（ネットワーク上で送信される数バイト）。もう1つ、必要なときにメッセージ本文を書くのを忘れないようにすることもできます。
応答で単純に成功ステータスを返すのではなく、httpエラーコードは成功またはエラーを通知するだけです。アプリケーション固有のエラーコードやエラーメッセージなどの詳細なエラー情報を追加するために、応答自体を使用することだけを含めます。
PUT、PATCH、およびPOSTリクエストの場合、通常は空の応答ではなく、リクエストが適用された後のリソースの状態を返します。
単にリソースを作成する代わりにアクションを表すPOSTリクエスト（あまりRESTfulではないが、実際にはまだ有用））の場合、返すべき有用なデータがないため、応答を返します。空のjsonオブジェクトで構成される、つまり{}。そうすれば、クライアントは有効な応答を受け取り、後でいくつかの情報を追加しても、それが壊れることはほとんどありません。
DELETEリクエストの場合、204と空の本文を返すことはかなり一般的です。これは、リソースが後で存在しないため意味があります。
必要なものだけを返すことと、少し明確にすることをお勧めします。
たとえば、APIの使用方法に応じて、保存後に存在するオブジェクトのコピーを含めることができます。
したがって、POST of {key：123}は{key：123、foo： 'bar'}を返す可能性があります。
基本的な考え方は、オブジェクトを返してから再度クエリする必要があることです。
とはいえ、APIコンシューマーの中でオブジェクトを必要としない場合は、オブジェクトを返す必要はありません。
POST PUT and PATCHで必要なオブジェクトがない場合、通常は{成功：true}などを返します。これは、受信側にとってより簡単になるため、PUTおよびPATCHです。それは、オブジェクトの保存された表現を返すための時間、とにかくそれを必要としないことはまれであり、1つの要求ですべてを送信してから2つの要求ですべてを送信することは「安価」です。
具体的には、ラボではステータスコードだけですべてを処理できることが完全にわかります。現実の世界では、たとえ冗長であっても一部のデータを返す方がはるかに優れているため、APIの利用者はあなたの発言を簡単に理解できます。
200 {成功：true}を返すと、人々は両方の方法でコードを書くことができます：
if response.code == 200
do stuff
end
そして
if response.body.success
do stuff
end
さらに、あなたの側でそれを行うことはそれほど難しくありません。
最後に、（poosの回答構造については申し訳ありません）パブリックJSON APIを提供することで、それがどのように使用されるかについて多くの制御を放棄します。一部のクライアントは、異なる本体（またはその欠如）またはステータスコードに対して異なる反応をする場合があります。