0

Web アプリケーション用の REST API を設計しています。

API を設計する際の私の原則は次のとおりです。

  • データ モデルの視点ではなく、クライアントユース ケースの視点を使用します。動機: DB スキーマからの抽象化。
  • 各スラッシュは、新しいユース ケース/アクションを表します。

アプリケーションには、ユーザー、製品、場所、製品ニュースがあるとしましょう。ユースケースは、ユーザーがある場所から製品ニュースをフォローすることです。場所が空の場合、ユーザーは各場所の製品に関するニュースをフォローします。
製品と場所のリストはよく知られています。

特定の製品と場所の組み合わせのフォロワーとしてユーザーを追加する正しい方法は何ですか?

次の URL に行き着きます。

/product/follow?product=<product_name>[&location=<location name>]

および名前は、将来拡張する柔軟性が高いため、クエリ部分にありますproduct。location

  • PUTの引数: もちろん、このリクエストはべき等です。複数回送信しても、1 回送信した場合とは異なり、他の変更は行われません。
  • POSTの引数: リソースが設定される URL は指定しません。

個人的には、APIのユース ケースの原則 (私はこれが正しいと考えています) により、インポテンシールールが最も対応するものであると判断できるため、PUTに近いと言えます。

4

1 に答える 1

1

最初にリソースを識別します。私はそれを言うだろう

/products/<product_name>/followers

は、 をフォローしているすべてのユーザーのリストですproduct_name。クエリ パラメータを使用してフィルタリングできます。

/products/<product_name>/followers?location=<location_name>

product_nameはからフォローしているすべてのユーザーのリストですlocation_name。

このGETようなリソースに対するリクエストは、ユーザーのリストの表現 (JSON、XML など) を返します。

POST またPUT

このPOSTようなリソースに対するリクエストは、新しいユーザーを追加します。このようなリクエストのリクエストボディにPOSTは詳細が含まれます。

POST /products/<product_name>/followers
Content-Type: application/json

{
  "user": "some user",
  "location: "some location"
}

サーバーは次のように応答します。

201 Created
Location: /products/<product_name>/followers/some%20user

クライアントが URI を知っている場合は、以下を使用できますPUT。

PUT /products/<product_name>/followers/some%20user
Content-Type: application/json

{
  "location: "some location"
}

サーバーは再び応答します。

201 Created
Location: /products/<product_name>/followers/some%20user

概要

クライアントが URI を正確に認識できる場合は、PUT. URL はサーバーのみが認識できますPOST。

于 2013-09-05T07:16:11.150 に答える