規則によって返されるREST PUT / POST / DELETE呼び出しは何ですか？
「RESTイデオロギー」によると、PUT/POST/DELETEリクエストの応答本文には何が含まれている必要がありますか？
戻りコードはどうですか？
HTTP_OKで十分ですか？そのような慣習がある場合、その理由は何ですか？
POST/PUTの違いを説明する良い投稿を見つけました： POST vs PUT しかし、それでも私の質問には答えません。
軽微ですが、HTTPでRESTを実行している場合、 RFC7231 はGET、PUT、POSTおよびDELETEから予想される動作を正確に記述します。
更新（14年7月3日）：
HTTP仕様では、POSTまたはDELETEから返されるものを意図的に定義していません。仕様では、定義する必要があるもののみを定義しています。残りは選択する実装者に任されています。
全体的に、規則は「あなたがWebページを配信しているように考えてください」。
PUTの場合、直後にGETを実行した場合に取得するのと同じビューを返します。その結果、200になります（もちろん、レンダリングが成功すると仮定します）。 POSTの場合、作成されたリソースへのリダイレクトを行います（作成操作を行っていると仮定します。そうでない場合は、結果を返します）。正常に作成された場合のコードは201です。これは、実際には300の範囲にないリダイレクトの唯一のHTTPコードです。
DELETEが何を返すかについて、私は決して満足していません（この場合、私のコードは現在HTTP 204と空のボディを生成します）。
通常、リソースの作成はPOSTにマップされ、新しいリソースの場所が返されます。たとえば、Rails scaffoldでは、CREATEは新しく作成されたリソースのSHOWにリダイレクトします。同じアプローチが更新（PUT）に意味があるかもしれませんが、それは慣習ではありません。更新は成功のみを示す必要があります。削除もおそらく成功を示すだけで十分です。リダイレクトしたい場合は、おそらくリソースのリストを返すのが最も理にかなっています。
はい、HTTP_OKで成功を示すことができます。
上で述べたことの中で唯一の難しいルールは、CREATEは新しいリソースの場所を返すということです。それは私にとって簡単なことのように思えます。クライアントが新しいアイテムにアクセスできるようにする必要があることは完全に理にかなっています。
RFC7231によって、それは重要ではなく、空であるかもしれません
プロジェクトでJSON API標準ベースのソリューションを実装する方法：
post/put：getのようにオブジェクト属性を出力します（フィールドフィルター/関係は同じように適用されます）
削除：データはnullのみを含みます（欠落しているオブジェクトの表現のため）
標準削除のステータス：200