回答:
余裕を許しますが、REST over HTTPを実行している場合、RFC7231は、GET、PUT、POST、およびDELETEから予想される動作を正確に記述します。
更新（2014年7月3日）：
HTTP仕様では、POSTまたはDELETEから返されるものを意図的に定義していません。仕様は、何を定義する必要があるかを定義するだけです。残りは選択する実装者に任されています。
全体として、この規則は「Webページを配信しているようなものだ」と考えています。
PUTの場合、直後にGETを実行した場合と同じビューが返されます。その結果、200になります（もちろん、レンダリングが成功した場合）。POSTの場合、作成されたリソースにリダイレクトします（作成操作を実行していると想定します。そうでない場合は、結果を返します）。正常に作成されたコードは201です。これは実際には、300の範囲にないリダイレクトの唯一のHTTPコードです。
DELETEが何を返すかについて満足したことはありません（このコードでは、現在のところ、HTTP 204と空の本文を生成しています）。
PUT結果のページにリフレッシュするので、次のページが悪い習慣のように思える要求リターンが再び実行するリクエストが発生します。代わりに、私にとっては、同期リクエストを処理していると想定して、リダイレクトを行うことは理にかなっています。
PUT、データを元に戻す別の要求を送信することを望まないことです。たとえば、2人が同じページを参照している場合、一方が更新を行い、次にもう一方が更新を行います。最初の人が更新して結果を確認すると、実際には、2番目の人が行う前の状態に戻ります。彼らの変化。
通常、リソースの作成はPOSTにマッピングされ、新しいリソースの場所が返されます。たとえば、Railsの足場では、CREATEは新しく作成されたリソースのSHOWにリダイレクトします。同じアプローチが更新（PUT）にも意味があるかもしれませんが、それは慣例ではありません。更新は成功のみを示す必要があります。削除はおそらく成功を示すだけで十分です。リダイレクトしたい場合は、リソースのリストを返すことがおそらく最も理にかなっています。
はい、HTTP_OKで成功を示すことができます。
上記で述べたことの唯一の厳格なルールは、CREATEは新しいリソースの場所を返す必要があるということです。それは私には簡単なことのようです。クライアントが新しいアイテムにアクセスできる必要があることは完全に理にかなっています。
私はアルフォンソティエンダが好きです 更新と削除のHTTPステータスコードですか？
ここにいくつかのヒントがあります：
削除
200（応答で追加のデータを送信する場合）または204（推奨）。
202削除された操作はまだコミットされていません。
削除するものが何もない場合は、204 または 404を使用します（DELETE操作はべき等であり、既に削除されたアイテムの削除は操作成功なので、204を返すことができますが、べき等は必ずしも同じ応答を意味するわけではありません）
その他のエラー：
- 400 Bad Request（不正な構文または不正なクエリは奇妙ですが可能です）。
- 401 不正認証の失敗
- 403 Forbidden：承認エラーまたは無効なアプリケーションID。
- 405 許可されない。承知しました。
- 409 リソースの競合は、複雑なシステムで発生する可能性があります。
- および501、502エラーが発生した場合です。
置く
コレクションの要素を更新する場合
- 上記のDELETEと同じ理由で200/204。
- 操作がまだコミットされていない場合は202。
参照された要素は存在しません：
PUTは201にすることができます（これがあなたの振る舞いであるので要素を作成した場合）
404 PUTを介して要素を作成したくない場合。
400 Bad Request（不正な構文または不正なクエリがDELETEの場合よりも一般的）。
401 無許可
403 Forbidden：認証失敗または無効なアプリケーションID。
405 許可されない。承知しました。
409 リソースの競合は、DELETEなどの複雑なシステムで発生する可能性があります。
422 Unprocessable entityこれは、「不正なリクエスト」（たとえば、不正なXML / JSON）と無効なフィールド値を区別するのに役立ちます
および501、502エラーが発生した場合です。