11

私はここ数日、「本物の」RESTful APIを読んでいますが、それが何であるかについてはもうすぐだと思います。

しかし、私がつまずいたことの1つは、「実際の」ハイパーメディアAPIのクライアントをどのように作成するかを想像することすらできないということです。

  1. 私が読んだ例のほとんどはブラウザとスパイダーについて話しますが、それは特に役に立ちません。1つは人間主導で「インテリジェント」であり、もう1つは愚かで「ランダム」です。現状では、クライアントを機能させるにはAIを学ぶ必要があるという印象を受けます。

  2. 私にははっきりしないことの1つは、クライアントが特定のリンクで使用する動詞をどのように知っているかということです。これは、URIの「rel」タイプに暗黙的に含まれていますか？別の方法（ここを読んでください）は、xhtmlを使用し、フォームを解析して投稿できるクライアントを持っているようです。

  3. リンクが変更される可能性はどのくらいありますが、リンクへのルートは変更されませんか？周りにあるほとんどの例では、ルートとリンクは同じです。

例えば。Toni's CakeShopからケーキのリストを戻すクライアントを設定したい場合：

http://tonis.com
{ link: { type : "cakes" ; uri : "http://tonis.com/cakes" } }

Toni'sがToni'sFoodShopになり、リンクがなるとどうなりhttp://tonis.com/desserts/cakesますか？

cakes下位互換性のために、ルートに最初のリンクを保持しますか？そうでない場合は、「ルートに移動してケーキを探す」と言われたかわいそうな小さなエージェントを「リダイレクト」するにはどうすればよいでしょうか。

私は何が欠けていますか？

4

2 に答える 2

10

わかりました。私もRESTの専門家ではありません。最近、関連するものをたくさん読んでいます。そのため、これから書くのは、私の経験や意見ではなく、読んだ内容の要約、特にRESTInPracticeです。本。

まず第一に、クライアントとサーバーの間で最初の合意を得るのを免れることはできません。RESTの目標は、クライアントとサーバーの両方に関連する最小限のことについて合意させ、各当事者に自分のことを気にかけてもらうことです。彼ら自身。たとえば、クライアントはリンクのレイアウトやデータがサーバーに保存される方法を気にする必要はなく、サーバーはクライアントの状態を気にする必要はありません。彼らが事前に（つまり、対話が始まる前に）同意するのは、前述の本の著者が「ドメインアプリケーションプロトコル」（DAP）と呼んでいるものです。

DAPの重要な点は、HTTP自体はステートフルではないにもかかわらず、ステートフルであることです（クライアントとサービスの相互作用には、少なくとも開始と終了の状態があるため）。この状態は、「クライアントが次にできること、できること、期待すること」の観点から説明できます。「サービスの使用を開始しました。今は何ですか？OK、アイテムを検索できます。このアイテムを検索して、次は何ですか？OK 、これとあれを注文できます...など」

ハイパーメディアコンテンツタイプの定義は、データ交換と相互作用状態の両方を処理できることです。すでに述べたように、状態は可能なアクションの観点から説明されており、RESTの「リソース」から来るように、すべてのアクションはアクセス可能なリソースの観点から説明されています。頭字語「HATEOAS（アプリケーション状態のエンジンとしてのハイパーメディア）」を見たことがあると思いますが、それは明らかにそれが意味することです。

したがって、サービスと対話するために、クライアントは両方が理解するハイパーメディア形式を使用します。これは、標準、自家製、またはそれらの混合（XML / XHTMLベースなど）です。それに加えて、HTTPである可能性が最も高いプロトコルも共有する必要がありますが、一部の詳細が標準から省略されているため、「POSTを使用してリソースを作成し、PUTを使用して更新する」などの使用法のイディオムが必要です。 。また、そのようなプロトコルには、サービスのエントリポイントが含まれます（ここでも、アクセス可能なリソースの観点から）。

これらの3つの側面は、ドメインプロトコルを完全に定義します。特に、クライアントは、サービスの使用を開始する前に内部リンクを認識したり、対話の完了後にそれらを記憶したりすることは想定されていません。その結果、名前の変更などの内部ナビゲーションの変更は、クライアントが最初の合意を遵守し、正面玄関から店に入るとすぐにクライアントに影響を与えることはありません/cakes。/f5d96b5c

于 2012-03-09T18:45:41.147 に答える
8

@ベンジョル

特定のURIに対してクライアントをプログラムすることは避けなければなりません。リンクを説明するとき、主な重要性はURI自体ではなく、その意味を持っています。URIはいつでも変更できますが、これによってクライアントが破損することはありません。

私はあなたの例をこのように変更します：

{"link": {
  "rel":   "collection http://relations.your-service.com/cakes",
  "href":  "http://tonis.com/cakes",
  "title": "List of cakes",
  "type":  "application/vnd.yourformat+json"
}}

サービスを利用するクライアントがある場合は、次のことを理解する必要があります。

  • リンク構造自体
  • リンク関係（この場合、RFCである「コレクション」とドメイン固有のリンク関係である「http://relations.your-service.com/cakes」）

この場合、クライアントは「href」属性で指定されたアドレスを逆参照して、ケーキのリストを表示できます。後で、ケーキリストプロバイダーを変更しても、URIクライアントは引き続き機能します。これは、クライアントがメディアタイプのセマンティクスを引き続き理解していることを意味します。

PS

于 2012-06-01T17:31:01.233 に答える