4

ハイパーメディア ベースの API を構築しようとしています。物事はうまくいっているようです。フェッチ/books/isbn/12313441213すると、次のようなものが得られます。

<book>
  <id>123</id>
  <name>Hypermedia APIs</name>
  <description>Basic api design techniques</description>
  <tags>
    <tag>rest</tag>
    <tag>api</tag>
    <tag>service</tag>
  </tags>
  <authors>
    <link rel="author" uri="/authors/id/22" />
    <link rel="author" uri="/authors/id/18" />
  </authors>
</book>

これで、このリソースから著者をたどることができます。フェッチする/books/by/author/id/18と、次のようなものが得られます。

<books>
  <book id="123">
    <name>Hypermedia APIs</name>
    <link rel="self" uri="/books/id/123" />
  </book>
  <book id="191">
    <name>Chef Recipes for Rails Developers</name>
    <link rel="self" uri="/books/id/191" />
  </book>
  <book id="220">
    <name>Rails 4 Cookbook</name>
    <link rel="self" uri="/books/id/220" />
  </book>
  <book id="292">
    <name>Ruby 102</name>
    <link rel="self" uri="/books/id/292" />
  </book>
  <book id="432">
    <name>Semantic Architecture</name>
    <link rel="self" uri="/books/id/432" />
  </book>
  <book id="501">
    <name>Service Oriented Design</name>
    <link rel="self" uri="/books/id/501" />
  </book>
</books>

これも私にとってはうまくいっているようです。この uri テンプレート化の方法が良いかどうかにかかわらず、私の質問は、このようなリンクをたどるのがどれほど実用的かということです。

リソースの完全な詳細 (作成者の詳細を含む) が必要であることを考慮すると、サーバーに対して少なくとも 3 回の呼び出しを行う必要があります。繰り返しになりますが、コレクションについては、サーバーに対して大量の呼び出しを行う必要があります。はい、ここでリソースの拡張を利用できるかもしれませんが、すべてのクライアントが時間内に拡張されたリソースを使用するため、ハイパーメディア リンクを使用する必要はありません。

クライアントがリンクをトラバースできるようにすることで、多くのことが得られていることを理解しています (つまり、クライアントがリレーション ベースのリソース ディスカバリを構築する場合、API を変更しても最小限の影響を受けるか、リソース エンドポイント自体から最新のスキーマを取得する必要があります。等）。繰り返しになりますが、このアプローチの実用性、またはこのアプローチのパフォーマンスは、システムを殺します。

ハイパーメディア api の設計で何かを得ていないか、ハイパーメディア api は素晴らしいように聞こえますが、それは単なる理論的なアイデアであり、実用的なアイデアではないようです。

これについて何か考えはありますか？

4

2 に答える 2

1

パラメータを使用する方がより伝統的です。

GET /books?author=18

応答は次のようになると思います。

ハイパーメディア API

パラメータを使用して、サブリソースのどのフィールドを表示するかを示すこともできます。何かのようなもの

GET /books/18?expand=著者(名前、誕生日)

これは、応答の author タグの一部として著者の名前と誕生日を返します。次に、ユーザーが本を要求したときにどのくらいの著者情報を取得するかについて妥当なデフォルトを提供できます (著者の自己と名前だけかもしれません) が、パラメーターを変更することで、必要に応じて詳細を取得できます。

このようなカスタマイズは、必要な呼び出しの数を減らすのに役立ちます。

もう 1 つの観察結果は、クライアントまたは中間プロキシのいずれかに、このデータの多くをキャッシュできることです。本や著者に関して大きな変更が生じる可能性は低いため、これらのリソースにより、クライアントはそれらを長期間キャッシュすることができます。その場合、往復はまったくありません。クライアントは、データ用に独自のローカル キャッシュにアクセスします。

于 2013-08-08T00:10:32.593 に答える