web-dev-qa-db-ja.com

専用のAPIエンドポイントまたは汎用リソースへの複数の呼び出し？

この問題は、AJAXを介してサーバーと通信するSPA WebアプリケーションのAPIを設計しているときに発生しました。

1つのページで、イベントに招待する人のリストを作成しているユーザーは、以前のイベントに招待された人を追加することができます。以前のイベントの名前を含むドロップダウンを想像してください。イベントが選択されると、前のイベントに招待された全員が複数選択に入力されます。ユーザーはこれらのユーザーから選択して[追加]を押すと、現在のイベントの招待リストに追加されます。

説明したドロップダウン/複数選択の背後にあるデータ構造を想像すると、次のようになります。

previousEventGuests [
  { 
    eventName: 'Company Christmas Dinner',
    guests: ['Joe Smith', 'Andy Jones', ...]
  },  
  ...
]

問題が発生します：この情報はどのようにAPIからダウンロードされますか？

私は2つの高レベルのアプローチを見ます：

  1. この特定のニーズに対処する特定のAPIエンドポイントを記述します。

    /previousEventsAttendees

上記のデータを正確に返します。

  1. 汎用リソースエンドポイントを複数回呼び出す

    /events                    (foreach event_id returned, call....)
  /event/:event_id         (to get each event's name)
  /event/:event_id/guests  (forach list of user_ids returned, call...)
    /user/:id              (to actually get each users name)

1.の長所は、1つのAJAX呼び出しを行うだけで済み、クライアントでのデータ処理コードがはるかに少ないことです。主な欠点は、この特定のアプリケーション内のこの特定のビューに密結合されたエンドポイント。

2.の長所は、汎用リソースエンドポイントのみを使用していることです。これは、多くの異なるビューやアプリケーションで再利用できます。短所は、多くのAJAX=呼び出しを行い、必要な形式を取得するためにすべての応答をつなぎ合わせる必要があることです。

私の質問は次のとおりです。1.これらの種類の決定を行う際に考慮すべき要素は何ですか？このAPIが一般公開されているAPIではなく、社内のAPIである（そしてほぼ確実に残る）という事実が私の決定に影響を与える必要がありますか？両方の世界を最大限に活用する方法はありますか？ 2.これはRESTの原則に関連する一般的な問題であり、多くの解決策があることを知っています（Falcorは少なくとも同様の問題を解決するための新しいアプローチだと思います）。他のアプローチを検討すべきですか？

designrestapiapi-design
6
Jonah

なぜ両方ではない？

つまり、はい、考慮すべきトレードオフがありますが、2番目のオプションを実装するための限界コストが小さい場合は、クライアントが希望する表現を選択できるようにして、クライアントが独自のトレードを選択できるようにすることができます。オフ（もちろん、クライアントの「問題」を解決するのではなく、選択肢を提供することによって支払われる複雑さのペナルティがいくつかあります）。

私が目にする主な欠点は、この特定のアプリケーション内でこの特定のビューに密結合されたエンドポイントを構築したことです。

RESTの観点からは、適切な言語ではありません。アプリケーションに結合されているのはendpointではなく、表現のメディアタイプです。

もちろん、メディアタイプについての心配は、クライアントとサーバーの両方を実装していて、リリースサイクルが連動していると、途中で落ちる傾向があります。

2.の長所は、汎用リソースエンドポイントのみを使用していることです。これは、多くの異なるビューやアプリケーションで再利用できます。

その考えは不完全です。エンドポイントを再利用できるだけでなく、表現自体を再利用できます...つまり、キャッシング。クライアントが自身のキャッシュから必要なデータをプルできる場合は、ラウンドトリップする必要はまったくありません。これに失敗すると、中間キャッシュにすでにデータのコピーが含まれている可能性があり、往復が短縮されます。クライアントが通信している「サーバー」は、アプリの前のキャッシュファームであり、スケールアウトしながらワークロードを低く保つことができます。

RESTでは、デザインが統一されたインターフェースを利用することを確認したいとします。

したがって、考慮すべきことの1つは、リソースのキャッシュ存続期間です。表現はどのくらい有効ですか？他のビューやアプリケーションがそれを利用できるようになるのでしょうか？

このAPIが一般公開されているAPIではなく、社内のAPIである（そしてほぼ確実に残る）という事実が私の決定に影響を与える必要がありますか？

これにより、サポートする必要のあるトラフィックの量が制限される可能性があります。また、クライアントがすべて中央に配置される場合、往復時間も問題になります。

4
VoiceOfUnreason