私の答え: /users.json. HTTP は大粒のハイパーメディア転送用に最適化されています。キャッシングはこれの大部分を占めており、上記の URI スキームはいずれもキャッシュ フレンドリーではありません。
たとえば、Squid は一般的な HTTP キャッシュであり、既定ではクエリ文字列を含む URL はキャッシュされません。さらに、多くのクライアント、さらにはサーバーや仲介者でさえ、未定義の順序でクエリ文字列パラメーターを生成および使用します。つまり、「?a=3&b=5」は「?b=5&a=3」と任意に書き換えることができます。ただし、HTTP キャッシュの場合は順序が重要であり、2 つのページは同じコンテンツであっても別々にキャッシュされます。パラメータを追加すると、この問題は指数関数的に増加します。
リソース (およびその表現) は、次の 2 つの相反する補完的な手法によってキャッシュを利用できるように設計する必要があります。
- 断片化された部分的な表現をより大きな統一された表現に結合し、
- 統一された大規模な表現を、キャッシュ境界 (トランザクション境界になる傾向がある) に沿って小さな表現に分割しますが、ハイパーリンクで関連付けます。
あなたの場合、ステップ1は、関連付けとパーツを「ユーザー」表現に結合することを意味し、クライアントがどれをどれだけ構成するかを設定するオプションはありません。これにより、すべてのクエリ文字列オプションによる応答の組み合わせの爆発であなたの（およびそれらの）キャッシュを過負荷にすることなく、単一の応答表現を積極的にキャッシュすることができます。
/users.jsonステップ 2は、それぞれが「関連付け」リソースと「パーツ」リソースを持つ個別の「ユーザー」エンティティに分離することを意味します。そう/users/{id}そして/users/{id}/associationsそして/users/{id}/parts。次に、「/users」リソースは、個々の「/users/{id}」リソースへのハイパーリンクの配列を返し、各「/users/{id}」表現には、その関連付けと部分へのハイパーリンクが含まれます (その部分はより順応性があります- -アソシエーションとパーツをユーザーリソースに直接埋め込む方がアプリケーションに適している場合があります.これにより、データベース全体をキャッシュすることなく、「需要のある」リソースごとに応答を積極的にキャッシュできます.
そうすれば、ユーザーは「でも、ネットワーク トラフィックが 10 倍になる!」と叫びます。あなたは冷静に、「いいえ、それはネットワーク トラフィックの 1/10 です。要求されたリソースの 10 分の 9 は、クライアント側 (ブラウザー) のキャッシュに既に存在しているからです (そうでない場合は、1/10 です。それらはサーバー側のキャッシュにあるため、サーバーの計算リソースに影響を与えます。また、サーバー側のキャッシュにも存在しない場合は、サーバー上のスマート キャッシュのスタンプを回避します)。」
もちろん、/usersリソースが毎日 100 万人の新規訪問者にヒットするものである場合、最適化パスは異なる可能性があります。しかし、URIスキームの例に基づいているとは思えません。