安らかなPOST応答のための「ベスト」プラクティス

したがって、ここでは何も新しいことはありません。説明を求めているだけで、他の投稿では何も見つけられないようです。

私は思い切って新しいリソースを作成しています：

/books (POST)

ボディ付き：

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

新しいリソースのLocationヘッダーを含む201（Created）を返す必要があることはわかっています。

Location: /books/12345

自分では答えられないように思える質問は、サーバーが本文で返す必要があるものです。

私はよくこのタイプの応答をしました：

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

これを行った理由はいくつかあります。

1. 私はangularjsのようなフロントエンドフレームワーク用のAPIを書きました。私の特定のケースでは、角度リソースを使用しており、リソースを見つけるためにリソースのIDだけが必要になることがよくあります。応答本文でIDを返さなかった場合は、Locationヘッダーから解析する必要があります。
2. すべての本のGETでは、通常、IDだけでなくオブジェクト全体を返します。この意味で、クライアントコードは、IDをどこから取得するか（場所のヘッダーまたは本文）を区別する必要はありません。

今、私は本当に灰色の領域にいることを知っていますが、ほとんどの人は、リソース全体を返すことは「悪い」習慣だと言っています。しかし、サーバーがリソースに情報を変更または追加した場合はどうなるでしょうか。それは間違いなくIDを追加しますが、タイムスタンプのような他のものも追加するかもしれません。リソース全体を返さない場合は、POSTを実行し、IDを返してから、クライアントにGETを実行して新しいリソースを取得させる方が良いでしょう。

更新時にオブジェクト全体を返すことはあまり関係がないように見えますが、オブジェクトの作成時にオブジェクト全体を返すことが通常のユースケースでは悪い習慣である理由はほとんどわかりません。これは、少なくともIDを簡単に取得し、関連する場合はタイムスタンプを取得するのに役立ちます。これは実際、Railsで足場を組むときに得られるデフォルトの動作です。

最初のPOSTで取得できるデータを取得するために、IDのみを返し、その後GETリクエストを実行することには、何の利点もありません。

とにかくあなたのAPIが一貫している限り、あなたはあなたのニーズに最も合うパターンを選ぶべきだと思います。REST API imoを構築する正しい方法はありません。

新しいオブジェクトを返すことは、「ユニフォームインターフェイス-表現によるリソースの操作」のREST原則に適合します。完全なオブジェクトは、作成されたオブジェクトの新しい状態の表現です。

API設計についての非常に優れたリファレンスがここにあります：実用的なRESTful APIを設計するためのベストプラクティス

ここにはあなたの質問への回答が含まれています：更新と作成はリソース表現を返す必要があります

それは言う：

更新された表現のためにAPIコンシューマーがAPIを再度ヒットする必要がないようにするには、更新された（または作成された）表現を応答の一部としてAPIに返します。

私にとっては実用的だと思われ、上で述べたRESTの原則に適合します。