0

エンドポイントにアクセスしようとするユーザーに別の方法で応答したいリソース エンドポイントがあります。

シナリオ

リソース endpoint/usersと次のUserTypesがあるとします。

  • 女の子ユーザー
  • ボーイユーザー
  • 管理者

GirlUserGETがonを実行するとき、他のGirlUsers/usersのみがアクセスできるようにしたいと考えています。BoyUsersも同様の結果になり、Adminsはすべてのユーザーを受け取ると思います。

私の質問

それはよりRESTfulですか：

  1. /users1 つのエンドポイントを使用して、OAuth を介して異なる GrantTypes または Scopes でこれを処理します。
  2. users/girls、、 など、さまざまなエンドポイントがusers/boysありusers/allます。
  3. ユーザーの種類ごとに異なる API を用意します。
  4. 私は考えられる答えに完全に的外れであり、それは私が期待していないことです.

特定のUserTypeに対してのみ動作させたい他のエンドポイントがある場合、何か変更はありますか?

（例えば、支払いを処理するもの。）

ありがとうございました。

4

1 に答える 1

0

エンドポイントは、ユーザーの性別に依存しない必要があります。共通のユーザー エンドポイントを持つことの問題は何ですか。（あなたはすでにそれを正しくやっています!!）

返したい情報の種類や手元にあるリソースの種類にもよりますが。JSON/XML を返していますか? Girlバックエンドで使用するBoyクラスがあります。女の子のユーザーがエンドポイントにヒットした場合、オブジェクトをシリアル化し、データをユーザーに返します。これは問題ないように思えます。

UML 設計で女の子と男の子を区別しない場合は、同じエンドポイントを使用する必要があります。

問題を正しく理解するために、
i) どのようなデータを返していますか?
ii) UML をどのように設計しましたか?
iii) DB からデータを返していますか? エンドポイントがヒットするたびにすべての女の子/すべての男の子のクエリを実行するのはコストがかかりますか?

スコープに関しては、OAuth では通常、1 つのスコープが 1 つのエンドポイントに対応します。Google と同様に、G+ がスコープであり、Google ドライブがスコープです。G+ の女の子、G+ の男の子のスコープは表示されませんね。

Java の用語で言うと、API 設計に最も近いのは Factory パターンです (これは私が自分自身に説明した方法であり、技術的に正しくない可能性があります) - ユーザーのタイプに応じて、データを返す特定のメソッドを呼び出します。エンドポイントは汎用的で拡張可能でなければなりません。個別の API を持つことは、拡張の余地がほとんどないため、実際には悪い設計です。

于 2013-05-09T04:53:32.327 に答える