46

GET、POST、PUT、および DELETE を利用する RESTful Web アプリケーションを構築しようとしています。しかし、この特定のアプリでの DELETE の使用について質問がありました。

最初に少し背景を説明します。

私の webapp は、別のシステムでも管理されている (そして、たまたま常に作成されている) 一般的なエンティティを管理します。したがって、私の webapp 内では、各エンティティは一意のキーを使用してデータベースに格納されます。ただし、URL を介してそれらにアクセスする方法は、他のシステムの一意のキーを使用することです。

簡単な例でこれが明確になると思います。URL を取得します/entity/1。これにより、自分のシステムではなく、他のシステムのID 1 を持つエンティティの情報が表示されます。実際、システム内の ID は完全に隠されます。1私自身のシステムでは、 ID を持つエンティティにアクセスするための URL スキームはありません。

よし、これで私の webapp の構造がわかったので、それらのエンティティの削除に戻りましょう。

システムでエンティティを「削除」する方法がありますが、実際にはデータベースからエンティティを削除しないため、引用符で囲みます。むしろ、に移動したときに表示されないようにするプロパティでそれらにフラグを立てます/entity/1。

このため、データの観点から、プロパティを設定するだけなので、使用する必要があるように感じますPUT(この方法での「削除」は冪等になります)。

では、問題は、RESTful なアプローチにはデータに対する忠実性があるか (この場合、私がPUTing していることは明らかです)、それともアプリ内のデータの表現 (この場合、私がDELETEing しているように見えます) があるでしょうか?

4

3 に答える 3

75

を使用する必要がありますDELETE。

データに対して行うことを「ソフト削除」と呼びます。フラグを設定し、フラグが設定されたアイテムが表示されないようにします。これは webapp の内部的なものであり、ユーザーは削除ではなくソフト削除であることや、何をしたいのかを知る必要はありません。DELETEこれが、動詞を使用する必要がある理由です。

于 2013-04-05T16:42:11.433 に答える
-1

DELETE メソッドには HTTP の非常に特殊なセマンティクスがあり、REST API の設計によってオーバーロードしたり拡張したりしてはなりません。具体的には、API は、リソースとその URI をクライアントが利用できるようにする、より少ないアクションに DELETE をマッピングすることによって、DELETE の意図された意味を歪めるべきではありません。たとえば、API が「ソフト」削除またはその他の状態変更相互作用を提供したい場合、特別なコントローラー リソースを採用し、DELETE の代わりに POST を使用して相互作用するようにクライアントに指示する必要があります。

出典: Mark Massé による Rest-API Desgin ルールブック

提案:

POST: /entity/1/your-soft-delete-controller-name
于 2021-07-28T12:44:01.797 に答える