RESTful (ハイパーメディア) API 用のクライアントの作成

StackOverflow https://stackoverflow.com//questions/9634394

  •  10-12-2019
  •  | 
  •  

質問

ここ数日間、「本物の」RESTful API について読んでいます。 考える それが何なのか、もうすぐ理解できます。

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

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

  2. 私にとって明確ではないことの 1 つは、クライアントが特定のリンクでどの動詞を使用するかをどのようにして知るのかということです。それは URI の「rel」タイプに暗黙的に含まれていますか?代替案（読書 ここ）xhtmlを使用しており、フォームを解析して投稿できるクライアントがあるようです。

  3. リンクは変更されるが、リンクへのルートは変更されない可能性はどのくらいですか?よく見かけるほとんどの例では、ルートとリンクは同じです。

例えば。Toni's Cake Shop のケーキのリストを返すクライアントをセットアップしたい場合:

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

Toni's が Toni's Food Shop になり、リンクが http://tonis.com/desserts/cakes?

イニシャルを維持しますか cakes 逆互換性のために、ルートにリンクを追加しますか?そうでない場合、「ルートに戻ってケーキを探しなさい」と言われた哀れな小さなエージェントのために、どのように「リダイレクト」を行うのでしょうか?

私には何が欠けているのでしょうか？

役に立ちましたか？

解決

@benjol

特定の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"
}}
.

あなたのサービスを消費するクライアントがある場合は、理解する必要があります：

  • リンク構造自体
  • リンク関係（この場合は "Collection"がRFCである " http://relations.your-service.com/cakes "どちらのドメインです 具体的なリンク関係）

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

    p.S。

他のヒント

OK、私も REST の専門家ではありません。最近は関連するものをたくさん読んでいます。そのため、これから書くことは私の経験や意見ではなく、読んだ内容、特に 実践中の休息 本。

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

DAP について重要なことは、HTTP 自体はステートフルではないにもかかわらず、DAP がステートフルであるということです (クライアントとサービスの対話には少なくとも開始と終了の状態があるため)。この状態は、「クライアントが次に実行できること/実行できること/実行すると予想されること」という観点から説明できます。「サービスを使い始めたけど、どうなるの？」はい、アイテムを検索できます。このアイテムを検索したら、次は何ですか?わかりました、あれもこれも注文できます...等"

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

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

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top