「RESTイデオロギー」によれば、PUT/POST/DELETEリクエストのレスポンスボディには何が必要ですか？どのようなREST PUT/POST/DELETE呼び出しが規約によって返されるべきですか？
リターンコードはどうですか？ HTTP_OKで十分ですか？
このような慣習の理由は何ですか？
私は、POST/PUTの違いを説明良い記事を見つけた：POST vs PUT しかし、それはまだ私の質問に答えていません。
HTTPを介してRESTを実行している場合、RFC7231は、GET、PUT、POST、およびDELETEから予期される動作を正確に記述します。
全体として、規約は「あなたがウェブページを配信しているように思える」というものです。
PUTの場合は、直ちにGETを実行した場合と同じビューを返します。それは200になります（もちろん、レンダリングが成功すると仮定します）。 POSTの場合、作成されたリソースへのリダイレクトを行います（作成操作を行っていると仮定し、そうでなければ結果を返す）。作成に成功するためのコードは201で、実際には300の範囲にないリダイレクト用の唯一のHTTPコードです。
私は決してDELETEが返すべきものについて満足していません。（私のコードは現在、HTTP 204とこの場合は空のボディを生成しています）。
'PUT'リクエストを返すと、次のページは悪い習慣のように見えます。なぜなら結果のページをリフレッシュするとリクエストが再び実行されるからです。代わりに、私には、同期リクエストを処理していると仮定してリダイレクトを行うのが理にかなっています。 – lobati
@lobati私は同じ複数の同じPUT要求を送信することは、同じPUT要求の1つだけを送信するのと同じ結果を持っている必要があることに注意することが重要だと思います。おそらくあなたが上げた問題は、上記を考えるとそれほど重要ではないでしょうか？ – Iain
@Iainは本当にありません。問題は、他の人が後でレコードを更新した場合、別の 'PUT'リクエストを送信してデータを元に戻させたくないということです。たとえば、2人の人が同じページを参照している場合、1人が更新を行い、もう1人が更新を行い、最初の人物が更新されて結果を表示すると、2人目の人物が作成される前に彼らの変化。 – lobati
リソースの作成は通常、POSTにマップされ、新しいリソースの場所を返す必要があります。たとえば、Railsの足場では、CREATEは新しく作成されたリソースのSHOWにリダイレクトされます。同じ方法が更新（PUT）には意味があるかもしれませんが、それは規約のほうが少なくなります。アップデートは成功を示すに過ぎない。おそらく削除だけで成功を示す必要があります。リダイレクトしたい場合は、リソースのリストを返すことがおそらく最も理にかなっています。
成功はHTTP_OKで示されます。
上記の唯一の厳密なルールは、CREATEが新しいリソースの場所を返す必要があるということです。それは私には間違いないようです。クライアントが新しいアイテムにアクセスできる必要があることは理にかなっています。
あなたは実際にPUTとPOSTを混在させました。 POSTは作成に使用され、PUTは更新（および作成）に使用されます。 PUTは冪等でなければならないが、POSTはそうではないことに注意する価値がある。 – Stevie
あなたは正しいです。私はそれらを切り替えました。 –
ええ、私はこの事実を逃した。ありがとうございました！これは、各 "メソッド"についていくつかの新しい意味を "発明"し、SQL操作にマッピングするよりも確かに論理的であるよりはるかに論理的です。 – tuxSlayer
@tuxslayer私はちょうどsnarkyしようとしていたとは思わなかったのでうれしいです。多くの人々は、RESTがHTTPメソッドの上に追加要件を追加すると考えるようです。しかし、そうではありません。追加の制約がありますが、HTTPメソッドの動作に実際には影響しません。 RFC2616は確実に従うべきガイドです。 –
私はリンクをありがとう。 :)それは私が停止し、私が使用しているツールについて考えるようになりました。あなたのポストとRFCを読んだ後、私は自分自身がRFCの残りの夜を参照していることがわかりました。このプロセスは、最初にHTTPプロセス、残りのプロセスは2番目と考えることができました。とても有難い。 –