REST API アーキテクチャ設計に関する情報を探しています。必要なデータは、複数のリソースにわたるビューの組み合わせであることがよくあります。クライアントがそれらを組み合わせることを期待しますか、それともクライアントに組み合わせを行う API を提供しますか?
たとえば、人々がイベントについて通知を受けるための REST API を書いているとしましょう。誰かが次の 2 つの方法のいずれかでイベントへの関心を示します。
- その人が興味を持っているイベントを定期的に開催する組織に参加する
- 通常は購読しない組織が運営する特定のイベントを検索してマークする
100
次の長い手順を実行することで、ユーザーのすべてのイベントを取得できます。
GET /user/100/organizations
戻り値123
GET /organizations/123/events
戻り値[15,16,20]
GET /user/100/savedevents
戻り値[35,36]
GET /events/15,16,20,35,36
すべてのイベントを返します
しかし、それはクライアントにとってかなり重いようです。クライアントが「このユーザーの興味深いイベントをすべて教えてください」と言えるようにしたいと思っています。
GET /user/100/events
...そして、サーバーがステップ 1 から 4 のすべてを実行してそれらを返す必要があることをサーバーに理解させる必要があります[15,16,20,35,36]
。イベントの詳細を取得します。
このように複数のリソースを横断するビューを作成することは理にかなっていますか?
編集:さらに説明します。/organizations/123/events
私がためらっているのは、クリーンなリソースであることがわかるからです。/events?organizations=123
if は、「organization=123 のリソース イベントをください」と言うのと同じです。についても同じです/user/100/organizations
。
しかし、 「give me resource events where organization=123」で/user/100/events
はありません。それは、「user=100 の組織の登録を取得し、それらの組織 ID を取得し、組織が 123 のイベントを取得し、user=100 の保存されたイベントを取得する」です。
3 つのステップ自体は、クリーンなリソース マッピングです。それらをまとめるのは面倒に思えます。しかし、クライアント (特に Web クライアント) にすべてのロジックを理解するよう依頼することも同様です。