17

ハイパーメディアの制約をアプリケーション状態のエンジン(HATEOAS)として受け入れる REST クライアントの実装を知っている人はいますか?

Sun Cloud APIは、それが文書化されている方法と、Ruby、Java、および Python の実装が進行中であるという趣旨の著者の声明から判断すると、有力な候補のようです。しかし、これまでのところ、コードの痕跡は見つかりませんでした。

私は何でも探しています - 部分的な実装でも役に立ちます。

4

5 に答える 5

12

最初に確認する必要があるのは、一般的な Web ブラウザーです。これは、HATEOAS を (少なくともある程度は) 採用するクライアントの標準です。

これがハイパーメディアの仕組みです。それはとても簡単なので、ほとんど苦痛です：

  1. あなたはあなたのブラウザを指すhttp://pigs-are-cool.org/
  2. ブラウザーは HTML ページ、画像、CSS などを読み込みます。
    • この時点で、アプリケーション (ブラウジング エクスペリエンス) は特定の URI にあります。
    • ブラウザはそのURIのコンテンツを表示しています
  3. アプリケーションにリンクが表示されます
  4. あなたはリンクをクリックします
  5. ブラウザはリンクをたどります
    • この時点で、アプリケーションは別の URI にあります
    • ブラウザは新しい URI のコンテンツを表示しています

次に、2 つの用語が Web ブラウジング エクスペリエンスにどのように関連しているかを簡単に説明します。

  • ハイパーメディア = リンクが埋め込まれた HTML ページ
  • アプリケーションの状態 = 任意の時点でブラウザに表示されているもの。

したがって、HATEOAS は、Web ページから Web ページに移動したときに Web ブラウザーで何が起こるかを実際に説明しています。

リンクが埋め込まれた HTML ページは、いつでもブラウザに表示されるものを操作します

HATEOAS という用語は、このブラウジング体験を抽象化したものにすぎません。

RESTful クライアント アプリケーションのその他の例には、次のものがあります。

  • RSS リーダーとフィード リーダー。ユーザーから提供されたリンクをたどる
  • ほとんどの AtomPub ブログ クライアント。必要なのはサービス ドキュメントへの URI だけで、そこから、画像やブログ投稿、検索などをアップロードする場所を見つけます。
  • おそらく Google Gadgets (および類似のもの) ですが、それらは別のスキンのブラウザーにすぎません。
  • Web クローラーも RESTful クライアントですが、ニッチ市場です。

RESTful クライアント ソフトウェアの特徴:

  • クライアントは、何らかの URI でプライミングされ、サーバーが期待される結果 (例えば、Atom ブログ クライアント、Atom サービス ドキュメント) で応答する場合、任意のサーバーと連携します。
  • クライアントは、サーバーが URI をどのように設計するかについて、実行時にわかること以外は何も知りません。
  • クライアントは、サーバーが何を言っているのかを理解するのに十分なメディア タイプとリンク関係を知っています (例: Atom や RSS)。
  • クライアントは埋め込みリンクを使用して他のリソースを見つけます。いくつかは自動的に ( のように<img src=) いくつかは手動で (のように<a href=) です。

非常に多くの場合、それらはユーザーによって駆動され、GoogleBot などを除いて、正しく「ユーザー エージェント」と呼ぶことができます。

于 2010-07-09T12:38:46.153 に答える
6

Restfulieは、HATEOAS を使用するクライアントとサーバーを構築できるようにすることを目的とした、Ruby、Java、および C# のフレームワークです。使っていませんが、面白そうです。

Java プロジェクトのコード例を次に示します。

Order order = new Order();

// place the order
order = service("http://www.caelum.com.br/order").post(order);

// cancels it
resource(order).getTransition("cancel").execute();

繰り返しますが、これが何をするのか、または実際にどれだけうまく機能するのかは正確にはわかりませんが、興味深いようです.

于 2010-02-19T18:38:45.923 に答える
2

REST HTTP と HATEOAS の問題は、リンクを指定する共通の方法がないことです。そのため、サービス プロバイダーによって構造が変わる可能性があるため、リンクをたどるのが難しくなります。<link href="..." />他の人はリンクの独自の構造を使用する人もいます。<book href="..." />. リンクが定義された標準の一部である HTML やアトムとは異なります。

クライアントは、リンクの標準または従来の表現がない限り、メディアの種類がわからないため、表現内のリンクが何であるかを知ることができません

于 2010-06-10T12:11:27.110 に答える
1

HATEOAS 設計原則 (REST も設計原則のセットです) は、各リソースが最大で 1 つの固定 URL を持つ必要があることを意味します。

関連する他のすべては、「ハイパーメディア」リンクを介してその URL から動的に検出できる必要があります。

ここでウィキペディアのスタブを開始しました

于 2009-07-25T07:47:19.733 に答える
1

そんな中、Spring HATEOAS プロジェクトがあります。クライアント実装もあります: https://docs.spring.io/spring-hateoas/docs/current/reference/html/#client

Map<String, Object> parameters = new HashMap<>();
parameters.put("user", 27);

Traverson traverson = new Traverson(URI.create("http://localhost:8080/api/"), MediaTypes.HAL_JSON);
String name = traverson
    .follow("movies", "movie", "actor").withTemplateParameters(parameters)
    .toObject("$.name");
于 2021-08-27T14:31:23.997 に答える