1

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

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

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

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

destroy メソッドには、破棄と復元という 2 つの目的があるため、この方法にはあまり満足できません。

コントローラーで専用の復元アクションを作成できますが、REST の方法では、復元要求処理をどこに配置しますか? 専用コントローラーで？その場合、PUT または POST のどの方法を使用しますか?

4

4 に答える 4

2

REST 純粋主義者は、TrashController によって処理される Trash という新しいリソースを作成すると思います。復元を処理するには、Restore と呼ばれる TrashController に対するアクションが必要です。

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

http://example.com/trash/restore/{resourceId}
于 2009-06-04T23:59:09.723 に答える
1

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

このアクションがどこに進むべきかについては、それは本当にあなたの美的感覚と、Railsコントローラーをクリーンで整理された状態に保つこととRESTについてどれだけハードコアになりたいかによって異なります。

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

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

個人的には、Roy Fielding（RESTを定義する論文の元の著者）が出てきて、POSTには何も問題:put => :restoreはないと言って以来、BobsControllerで追加のメソッドとルートを定義することを検討します。これは、別のプログラマーが期待する場所にコードを保持し、この種の設計の唯一の対象者である可能性があります。

于 2009-06-05T05:37:39.547 に答える
0

上記のショーンは正しい方向に進んでいたと思いますが、さらに一歩進んでいきます。POSTリソースを。で更新するゴミ箱アクションを作成しますtrash=1。次に、復元は同じリソースPOSTへの別のものですtrash=0

編集：リクエストがリソース全体を送信するのではなく、リソースの一部を更新するだけである場合に、誤ったメソッドPUTを置き換えました。POST

于 2009-06-05T04:03:24.950 に答える
0

アクションはリソース上にあるため、機能は ResourceController に存在する必要があると思います。RESTFUL アーキテクチャに関する私の作業上の理解の 1 つは、PUT と POST のどちらを使用するかを決定する際の経験則は、POST は作成に使用され、PUT は更新に使用されるということです。この場合、リソースが「存在」し、PUT を使用して復元 URI を次のように更新している状態であることが期待されます。

http://example.com/resources/restore/ {id}

于 2009-06-04T23:34:47.743 に答える