本REST vs Too many Requests

偽のREST APIを非難する彼自身の記事に関するロイフィールディングのコメントから：

真にRESTfulなAPIはハイパーテキストのように見えます。すべてのアドレス可能な情報単位は、明示的に（たとえば、リンクとID属性）または暗黙的に（たとえば、メディアタイプの定義と表現構造から派生）のいずれかでアドレスを伝達します。クエリ結果は、オブジェクト表現の配列ではなく、要約情報を含むリンクのリストで表されます（クエリはリソースの識別の代わりにはなりません）。

これは、たとえば、最近ログインした100人のユーザーのリストをクエリして、その名前と電子メールを表示する必要がある場合、最初GETに結果のリストをクエリする必要があることを意味します。リンク要素のリストであり、各リンクオブジェクトにはユーザーリソースのURIが含まれます。結果を表示するために必要なデータを実際に取得する前に、さらに 100のGETリクエスト（ユーザーリソースごとに1つ）を行う必要があります。

それは信じられないほど非効率的です。1つまたは2つの要求で必要なデータを取得するための本当にRESTfulな方法は他にありませんか？

1つまたは2つの要求で必要なデータを取得するための本当にRESTfulな方法は他にありませんか？

• あんまり
• しかし、それを考えすぎないでください

いつものように、RESTについて考えるときは、チェックできる参照実装（World Wide Web）があることに注意してください。

Amazonポータルについて考えてみます。空のキャッシュでそのブックマークを開くと、ブラウザーが275個のリソースにリクエストを出しているのがわかります。

その状態のすべてが単一のペイロードでフェッチされた場合、レイテンシが向上しますか？はい。

それはスケーリングしますか？それはウェブスケールでしょうか？おそらく違います。これには、自分のプロファイルに固有の1KBが含まれているため、共有できない4.5MBのデータです。私の隣のデスクにいる私の同僚もAmazonに行くと、彼女は同じデータをネットワーク経由で引き出します。

そのペイロードを個別にアドレス指定可能なリソースに分解すると、突然物事が大幅に改善されます-私たちはそれぞれ1KBのパーソナライゼーションを取得し、それぞれにローカルにキャッシュされた4.5MBのコピーを持っていますが、ネットワークを強打する必要はありませんでしたなぜなら、ほとんどのリクエストはインターネット経由でルーティングする必要がなく、ローカルの共有キャッシュによって処理されたからです。

また、実際には複数のリソースに問題があるわけではなく、複数のリクエストに問題があることに注意してください。これは、キャッシュ可能な表現をサーバーが積極的にプッシュするHTTP / 2.0 Push Promisesを使用して軽減できます。たぶん-ステートレスサーバーはクライアントが何をキャッシュしたかを認識しておらず、TLSは中間でのキャッシュが優先事項ではないことを示唆しています...

つまり、たとえば、最近ログインした100人のユーザーのリストをクエリして、その名前と電子メールを表示する必要がある場合、最初に結果のリストに対してGETクエリを実行する必要があります。 ）リンク要素のリストであり、各リンクオブジェクトにはユーザーリソースのURIが含まれます。結果を表示するために必要なデータを実際に得る前に、さらに100個のGETリクエスト（ユーザーリソースごとに1つ）を行う必要があります。

もちろん、これをhtmlで行っている場合、最後にログインしたユーザーの表現は、おそらく名前と電子メールアドレスのリストまたはテーブルとそれらのリソースへのリンクを含むドキュメントになります。たーだ。

フィールディングによるこの観察を見失わないでください。

だからといって、RESTのアーキテクチャスタイルに基づいて独自のシステムを設計する必要があるとは思いません。RESTは、複数の組織にまたがる長期間有効なネットワークベースのアプリケーションを対象としています。制約が必要ない場合は、使用しないでください。

編集

JSON表現に対して同じ引数を作成できますか？つまり、問題のリソースがパラメーター化されたクエリの結果ではなく「最後にログインした100人のユーザー」である場合、リソースリンクの代わりにデータ自体を返すことができますか？そうでない場合、なぜですか？この点でJSONが本質的にHTMLと異なるのはなぜですか？

それらがどのように似ているか：より多くのデータを「結果のリスト」にパックすると、スケーリングを妥協しながら、追加のリクエストのコストを節約できます。表現に使用している特定のメディアタイプは関係ありません-少なくとも、私が知る限りでは。

それらがどのように異なるか：HTMLはハイパーメディア形式であり、JSONはそうではありません-HTML仕様に精通しているすべてのbog標準クライアント実装は、プリフェッチなどのオプションをサポートするHTMLドキュメント内のリンクを見つける方法を知っています。JSONにはその標準化がありません。リンクがJSON表現のどこにあるかを理解するには、データ構造に関する帯域外の情報が必要です。 この点で、HALはHTMLに近いものになります。HALとHTMLの主な違いは採用です。HTMLは20年前から始まっていますか？

追加の洞察については、エントリーとフィード（エントリーのリスト）の両方を説明するAtom Syndication Format、特にスタンドアロンリソースまたはフィードリソースを介してアクセスされるかもしれないatom：entryのルールを確認することを検討することもできます。