0

REST API アーキテクチャ設計に関する情報を探しています。必要なデータは、複数のリソースにわたるビューの組み合わせであることがよくあります。クライアントがそれらを組み合わせることを期待しますか、それともクライアントに組み合わせを行う API を提供しますか?

たとえば、人々がイベントについて通知を受けるための REST API を書いているとしましょう。誰かが次の 2 つの方法のいずれかでイベントへの関心を示します。

  • その人が興味を持っているイベントを定期的に開催する組織に参加する
  • 通常は購読しない組織が運営する特定のイベントを検索してマークする

100次の長い手順を実行することで、ユーザーのすべてのイベントを取得できます。

  1. GET /user/100/organizations戻り値123
  2. GET /organizations/123/events戻り値[15,16,20]
  3. GET /user/100/savedevents戻り値[35,36]
  4. GET /events/15,16,20,35,36すべてのイベントを返します

しかし、それはクライアントにとってかなり重いようです。クライアントが「このユーザーの興味深いイベントをすべて教えてください」と言えるようにしたいと思っています。

GET /user/100/events

...そして、サーバーがステップ 1 から 4 のすべてを実行してそれらを返す必要があることをサーバーに理解させる必要があります[15,16,20,35,36]。イベントの詳細を取得します。

このように複数のリソースを横断するビューを作成することは理にかなっていますか?

編集:さらに説明します。/organizations/123/events私がためらっているのは、クリーンなリソースであることがわかるからです。/events?organizations=123if は、「organization=123 のリソース イベントをください」と言うのと同じです。についても同じです/user/100/organizations

しかし、 「give me resource events where organization=123」で/user/100/eventsはありません。それは、「user=100 の組織の登録を取得し、それらの組織 ID を取得し、組織が 123 のイベントを取得し、user=100 の保存されたイベントを取得する」です。

3 つのステップ自体は、クリーンなリソース マッピングです。それらをまとめるのは面倒に思えます。しかし、クライアント (特に Web クライアント) にすべてのロジックを理解するよう依頼することも同様です。

4

2 に答える 2

2

私はあなたの質問に少し混乱していたので、できるだけ包括的にしようと思います.=P.

必要なデータは、複数のリソースにわたるビューの組み合わせであることがよくあります。クライアントがそれらを組み合わせることを期待しますか、それともクライアントに組み合わせを行う API を提供しますか?

真の RESTful 環境では、データのすべての横断ビューは、クライアントではなくサーバーによって行われます。

RESTful 設計の主な理由は、標準の HTTP 動詞 (例: 、、)を使用して CRUD モデル ( createreadupdatedelete ) にアクセスできるようにすることです。これらのメソッドの戻り値を、ある種のセッションまたはクッキー、またはその他の外部メソッド (たとえば、「ボブのデータを提供してください」、「ビジネスに関するデータを提供してください」、「最初の 2 つのクエリからのデータを提供してください」) に保存することは、それをはるかに超えています。 REST 方法論。 GETPOSTPUTDELETE

RESTful 開発を活用する方法は、メソッド呼び出しが一貫した RESTful 環境を提供するために、意味のある方法でリソースを組み合わせる方法を見つけることです。GETデータの読み取り、データのPOST作成、データのPUT更新、データのDELETE削除)。

したがって、ステップ 1 から 4 のようなことをしたい場合は、次のようなことをお勧めします。

GET /user/{userID}/organizations --> {return all affiliated organizations}
GET /user/{userID}/events --> {return all events associated with userID}
GET /organizations/{organization}/events --> {returns all eventID's assoc. with organization}
GET /user/{userID}/savedevents -->  {return all eventID's userID saved to their profile}
GET /events/?eventID=(15,16,20,35,36) --> {return all of the events details for those eventID's}
GET /events/{eventID}--> {return events details for {eventID}}

あなたも持っているかもしれませんが:

GET /events/  --> {return a complete listing of all event ID's}
GET /events/{userID}  -->  {return all events userID is associated with}
POST /event/  --> {create a new event - ID is assigned by the server}
POST /user/   --> {create a new user - ID is assigned by the server}
PUT /user/{userID}  --> {update/modify user information}

次に、情報の断面スライスが必要な場合は、断面の名前付きリソースを用意します (そうでない場合は、それを引数として渡します)。リソースを明示してください (参考までに、リソースは動詞ではなく名詞のみで名前を付けてください)。

あなたはまた尋ねました:

さらに説明します。私が躊躇しているのは、/organizations/123/events がクリーンなリソースであることがわかるからです。if は /events?organizations=123 と言うのと同じです。つまり、「organizations=123 のリソース イベントを教えてください」ということです。/user/100/organizations も同様です。

基本的に、named resourcedresource + argumentメソッドの両方で同じ情報を提供できます。通常、RESTful デザインの API が引数を呼び出すのは、重要な説明が必要な場合 (範囲要求、日付要求、非常に小さな単位のデータなど) に限られます。さらに解析/イントロスペクトできるデータの高次グループがある場合、それは名前付きリソースです。あなたの例では、RESTful仕様が複数のパスを介してデータを提供し、確立されたHTTPメソッドを使用することを要求しているため、両方のAPI呼び出しがあります。しかし、私も少し拡大します...

/events?organizations=123 -->  {return the eventID's associated with org=123}
/organizations/123/events  -->  {return event DETAILS for events associated with org=123}

Apigeeによるこの記事を読んでください

于 2013-10-06T13:53:42.237 に答える
0

これを解決するにはいくつかの方法があるかもしれません...しかし、ほとんどの場合(サービスが同じプロバイダーによって管理されている場合)、サーバー側にロジックを持ち、REST呼び出しをできるだけ独立したものにする方が良いと思います相互に可能です (つまり、必要な複数の操作を実行するサーバー - 通常、API リソースで処理されるデータを格納する DB からデータを読み取ります)。

これについて話している例では、REST API が「ユーザー」リソースとサブリソース「イベント」(「保存されたイベント」と呼ぶ) を公開することを意味します。これを念頭に置いて、次のようなものがあります。 :

  • POST /user/{username}/eventsユーザーが興味を持っている新しいイベント (または複数のイベント) を保存します
  • GET /user/{username}/eventsユーザーが関心のあるすべてのイベントを返します
  • GET /user/{username}/events/{eventid}特定のイベントの詳細を返します

組織 (およびその他のフィルタリング操作) ごとにユーザー イベントを「フィルタリング」するには、「クエリ パラメータ」を使用できます。

  • GET /user/{username}/events?organization=123

したがって、サーバー (または API 呼び出し) は、 のステップ 1 からステップ 4 で説明した操作を実行しますGET /user/{username}/events。API で他のリソース (「組織」と「イベント」) を作成することはできますが、それらは他のコンテキスト (新しいイベントや組織の保存など) で使用されます。

HTH

于 2013-10-06T13:18:35.450 に答える