HTTP仕様（ RFC 2616 ）には、適用可能な推奨事項がいくつかあります。これが私の解釈です。
- 既存のリソースへの更新のPUTが成功した場合のHTTPステータスコード
200 OK。レスポンスボディは必要ありません。 （Per Section 9.6 、204 No Contentがさらに適切です。） - 新しいリソースのPUTが成功した場合のHTTPステータスコード
201 Created。Locationヘッダーフィールドに返される新しいリソースの最も具体的なURI、および応答本文にエコーされるその他の関連するURIおよびメタデータ（ RFC 2616セクション10.2.2 ） - 3のために失敗したPUTのHTTP状況コード
409 Conflict第二試行された更新と応答本文の現在のリソースとの間の相違点のリストを含む、パーティによる変更。 （ RFC 2616セクション10.4.1 ） - 失敗したPUTのHTTP状況コード
400 Bad Request。応答本文にPUTが失敗した理由を説明する自然言語テキスト（英語など）が含まれています。 （ RFC 2616セクション10.4 ）
ここでの答えの大部分とは対照的に、私は実際にPUTは（もちろんHTTPコードに加えて）更新されたリソースを返すべきだと思います。
リソースをPUT操作の応答として返したい理由は、サーバーにリソース表現を送信するときにサーバーもこのリソースに何らかの処理を適用できるため、クライアントはこのリソースの処理方法を知りたいからです。リクエストが正常に完了した後のように見えます。 （そうでなければ、別のGETリクエストを発行する必要があります）。
サーバーがPUTに応答してコンテンツを返すことは可能だと思います。サイドロードされたデータを許容するレスポンスエンベロープフォーマット（ember-dataによって消費されるフォーマットなど）を使用している場合は、データベーストリガなどを介して変更された可能性のある他のオブジェクトも含めることができます。リクエスト数、そしてこれは最適化するのに最適な場所のようです。）
私がPUTを受け入れただけで、報告するものがない場合は、本文なしでステータスコード204を使用します。報告するものがある場合は、ステータスコード200を使用し、本文を含めます。
HTTP/1.1 spec （9.6節）は適切なレスポンス/エラーコードを論じています。しかしそれは応答内容を扱っていません。
何を期待しますか？単純なHTTP応答コード（200など）は、私にとっては単純明快です。
私は自分のサービスでRESTful APIを使っています、そして私の意見です：まず共通の見方をしなければなりません：PUTname__は作成も取得もしないリソースを更新するのに使われます。
Stateless resourceとStateful resourceでリソースを定義しました。
ステートレスなリソースこれらのリソースについては、空のボディでHttpCodeを返すだけで十分です。
ステートフルリソースたとえば、リソースのバージョン。この種のリソースでは、変更するときにバージョンを指定する必要があります。したがって、リソース全体を返すか、またはバージョンをクライアントに返すので、クライアントは更新アクションの後にget要求を送信する必要はありません。
しかし、、サービスやシステムでは、simplename__、clearlyname__、easy to use and maintainが最も重要です。
クライアントが新しく作成されたリソースを見つけることができる場所を指すための「Location」ヘッダーとともに「Created」の201というHTTP応答コード。
REST APIのバックエンドがSQLリレーショナルデータベースの場合、
- 更新可能なすべてのレコードにRowVersionを含める必要があります（ 失われた更新の問題 を回避するため）
- pUTの後には常にレコードの新しいコピーを返す必要があります（新しいRowVersionを取得するため）。
更新が失われたことを気にしない場合、またはPUTの直後にクライアントに強制的にGETを実行させる場合は、PUTから何も返さないでください。