0

Restful HTTP API を設計していますが、設計上の質問があります。

私のアプリケーションでは、ユーザーはアイテムの作成を提案できるはずです。

その後、私はそれらを承認または不承認にすることができます。

これに最適な VERB+URL パターンは何でしょうか。

例 1:

POST|GET|PUT|DELETE /items

ユーザーが新しいアイテムを投稿すると、「保留中」から「承認済み」にするか、削除することができます。

ここでは、GET /items?status=approved を使用してすべての承認済みアイテムを取得し、GET /items?status=pending を使用して保留中のすべてのアイテムを取得する必要があります。おそらく GET /items は、デフォルトで承認済みのものをすべて取得するでしょう。

しかし、ユーザーがそれを承認済みの状態にするのを防ぐ方法がわかりません。

また

例 2:

POST|GET|PUT|DELETE /item_creation_suggestions

ユーザーが新しいアイテムの提案を POST し、DELETE:ting して承認して POST /items を実行するか、単に DELETE することができます。

ここで /items と /item_creation_suggestions は 2 つの別個のコレクションです。提案を削除して、承認時にアイテムを作成するだけです。

これにより、アプリを不正アクセスから簡単に保護できます。/item_creation_suggestions は誰でも使用できますが、許可を得て自分の /items を保護することはできます。

しかし、これは非常に安らかではないようですか？

ユーザーがアイテムの更新と削除を提案し、私がそれらを承認または非承認する場合も同様です。

私は Restful デザインの初心者なので、すべてのフィードバックと提案を歓迎します!

4

2 に答える 2

2

最初の音はいいですね。

POST /items新しいアイテムを作成し、おそらくステータスを返す必要があり202 Acceptedます。
GET /items承認されたすべてのアイテムを返品する必要があります。
GET /items?status=pending適切な権限を持つユーザーに保留中のアイテムを返す必要があります。
PUT /items/[id]ステータスを変更するには、新しいステータスを指定するリクエスト ボディを使用します。
DELETE /items/[id]アイテムを削除します。

最終的には、 APIにとって何が最も理にかなっているかを判断する必要がありますが、上記は一般的に妥当に思えます。

于 2012-06-13T09:44:25.290 に答える
1

また、最初のセットアップを強く好みます。

しかし、ユーザーがそれを承認済みの状態にするのを防ぐ方法がわかりません。

アプリケーション ロジックでは、ユーザーが承認済み状態のアイテムを POST する権限を持っていない場合、それを防ぐ必要があります。REST は単なる「デッド ストレージ」ではありません。実際にリクエストを処理し、ユーザーが何か間違ったことをした場合に 403 Forbidden をスローすることができます。

アクセス制御は依然として重要であり、「安らぎ」に反するものではありません。

于 2012-06-13T09:48:41.673 に答える