REST MVC アプリケーションのどこで復元アクションを処理すればよいでしょうか?

Question

Rails アプリケーションのリソースを破棄した後、ユーザーはリンクをクリックしてリソースを復元できます。

現在、この復元アクションは、対応するリソース コントローラーの destroy メソッドにルーティングされます。

このメソッドはデータベース内でリソースを見つけると、それを破棄し、レコードをゴミ箱テーブルに移動します。

データベース内でリソースが見つからない場合は、ゴミ箱テーブル内でリソースを検索し、リソースが見つかった場合はそれを復元します。

destroy メソッドには次の 2 つの目的があるため、この方法にはあまり満足していません。破壊して復元する。

コントローラーに専用の復元アクションを作成することもできますが、REST の場合、復元リクエストの処理をどこに配置しますか?専用コントローラーで？もしそうなら、PUT と POST のどちらの方法を使用しますか?

Answer 1

POST は冪等ではありません。つまり、同じ POST リクエストを何度も送信すると、多くの新しいアイテムが取得されます。同じリソース上で同じ更新が複数回実行されても副作用がないはずなので、PUT は冪等である必要があります。

このアクションがどこに向かうべきかについては、あなたの美的感覚と、REST と Rails コントローラーをクリーンで整理された状態に保つことに対してどの程度熱心に取り組みたいかによって決まります。

確かに、DeletedBob が Bob とは異なるリソースであることは議論の余地があります。DeletedBobsController に送信された PUT は、おそらく更新の目的を示す「deleted=false」のようなパラメーターを使用して、DeletedBob リソースを更新すると言えます。

削除をリソースとして検討することもできます。次に、パラメータ「resource_type=bob&resource_id=23」を指定して DeletionsController で DELETE を使用できます。削除を破棄すると、元のオブジェクトが復元されます。後続の同一の呼び出しでは、DELETE で予想されるように、「オブジェクトが見つかりません」というエラーが発生します。

個人的には、Roy Fielding (REST を定義した論文の原著者) が世に出て、本当にあると言って以来、 POSTには何も問題はありません, 、追加の定義を検討します。 :put => :restore BobsController のメソッドとルート。他のプログラマが期待する場所にコードが保持され、おそらくこの種の設計の唯一の読者はプログラマです。

Answer 2

私は、RESTの純粋主義者は、TrashControllerによって処理されるゴミ箱と呼ばれる新しいリソースを作成すると思います。復元を処理するには、TrashController上のアクションが復元と呼ばれているだろう。

URLは次のようになります：

http://example.com/trash/restore/{resourceId}

Answer 3

私はアクションがリソース上にあるため、機能がResourceControllerに生きるべきだと思います。 RESTfulなアーキテクチャの私の作業understadingsの一つは、PUTやPOSTの間で決定する上で親指のルールが作成され、PUTが更新に使用されるためにPOSTが使用されていることであるということです。この場合、私は、リソースが「存在する」ことを期待し、あなたはそれがあなたのPUTを使用して、URIのようなものになるだろうと、復元状態です更新しています：

http://example.com/resources/restore/ の{ID}

Answer 4

私はショーンが上記右のトラックにあったと思いますが、私はさらに一歩それを取るでしょう。ゴミアクションPOSTでリソースを更新trash=1してください。ちょうど別のPOSTその後復元され、のと同じのtrash=0とリソース

EDIT：要求がリソース全体、リソースの一部だけ更新を送信していない所与PUTに置き換え誤っ方法POST