問題タブ [hateoas]

私がRESTについて知っていると思ったことの多くは明らかに間違っています-そして私は一人ではありません。この質問には長いリードインがありますが、情報が少し散らばっているので必要なようです。このトピックに既に精通している場合、実際の質問は最後になります。

RoyFieldingのRESTAPIの最初の段落から、ハイパーテキスト駆動型である必要があります。彼の仕事が広く誤解されていると彼が信じていることは明らかです。

HTTPベースのインターフェースをRESTAPIと呼ぶ人の数に不満を感じています。今日の例はSocialSiteRESTAPIです。それがRPCです。RPCを叫びます。ディスプレイには非常に多くのカップリングがあるため、Xレーティングを付ける必要があります。

フィールディングは、RESTAPIのいくつかの属性をリストします。それらのいくつかは、SOや他のフォーラムでの一般的な慣行と一般的なアドバイスの両方に反しているようです。例えば：

• REST APIは、最初のURI（ブックマーク）と対象読者に適した標準化されたメディアタイプのセット（つまり、APIを使用する可能性のあるすべてのクライアントによって理解されることが期待される）以外の事前知識なしで入力する必要があります。..。

• REST APIは、固定リソース名または階層（クライアントとサーバーの明らかな結合）を定義してはなりません。..。

• REST APIは、リソースの表現やアプリケーションの状態の駆動に使用されるメディアタイプの定義、または既存の標準メディアタイプの拡張リレーション名やハイパーテキスト対応のマークアップの定義に、ほとんどすべての記述的努力を費やす必要があります。..。

「ハイパーテキスト」の概念が中心的な役割を果たします。URI構造やHTTP動詞の意味よりもはるかに重要です。「ハイパーテキスト」は、コメントの1つで定義されています。

私が[フィールディング]ハイパーテキストと言うとき、私は情報とコントロールの同時提示を意味し、情報がユーザー（またはオートマトン）が選択肢を取得してアクションを選択するためのアフォーダンスになるようにします。ハイパーメディアは、メディアストリーム内に一時的なアンカーを含めるためのテキストの意味を拡張したものです。ほとんどの研究者はその区別をやめました。

ブラウザでは、ハイパーテキストはHTMLである必要はありません。マシンは、データ形式と関係タイプを理解すると、リンクをたどることができます。

この時点で推測していますが、上記の最初の2つのポイントは、次のようなFooリソースのAPIドキュメントがクライアントとサーバー間の緊密な結合につながり、RESTfulシステムには存在しないことを示唆しているようです。

代わりに、エージェントは、たとえば/ foosに対してGETリクエストを発行することにより、すべてのFoosのURIを検出するように強制する必要があります。（これらのURIは上記のパターンに従うことが判明する場合がありますが、それは重要ではありません。）応答は、各アイテムへのアクセス方法とそのアイテムで何ができるかを伝えることができるメディアタイプを使用し、上記の3番目のポイントを生じさせます。 。このため、APIドキュメントでは、応答に含まれるハイパーテキストを解釈する方法の説明に焦点を当てる必要があります。

さらに、FooリソースへのURIが要求されるたびに、応答には、エージェントがURIを介して関連リソースや親リソースにアクセスしたり、作成後にアクションを実行したりする方法を見つけるために必要なすべての情報が含まれます。 /リソースの削除。

システム全体の鍵は、応答がメディアタイプに含まれるハイパーテキストで構成され、それ自体が続行するためのエージェントオプションに伝達されることです。それは、ブラウザが人間のために機能する方法と同じです。

しかし、これはこの特定の瞬間における私の最善の推測です。

フィールディングはフォローアップを投稿し、彼の議論は抽象的すぎ、例が不足しており、専門用語が豊富であるという批判に応えました。

他の人は、私が書いたものを、より直接的であるか、今日のいくつかの実際的な懸念に適用できる方法で解読しようとします。次のトピックに取り組んだり、会議の準備をしたり、別の基準を書いたり、遠くの場所に旅行したり、給料をもらったと感じさせる小さなことをしたりするのに忙しいので、私はおそらくそうしません。

それで、実用的な考え方を持つREST専門家への2つの簡単な質問：フィールディングが言っていることをどのように解釈し、REST APIを文書化/実装するときにそれをどのように実践しますか？

編集：この質問は、あなたが話していることの名前がない場合、何かを学ぶことがどれほど難しいかの一例です。この場合の名前は「アプリケーション状態のエンジンとしてのハイパーメディア」（HATEOAS）です。

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

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

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

私が理解しているように、ハイパーテキスト駆動型のRESTful Webサービスを使用すると、クライアントは、いくつかのよく知られたエントリポイントを除いて、サーバーURIレイアウトについて何も知らないはずです。これにより、サーバーが独自のURIスペースを制御し、クライアントとの結合を減らすことができるようになります。

サービスのクライアントが新しいリソースを作成するための成功した要求を送信すると、サービスは201 CREATEDに応答し、新しいリソースにアクセスできるURIをLocationヘッダーフィールドに提供します。

将来、リソースへの直接アクセスを可能にするために、クライアントがこのURIを保存できるようにする必要がありますか？その場合、どのくらいの期間ですか？URIがクライアントによってキャッシュされている場合、これは、サーバーがURIレイアウトを変更するたびに、古いURIにアクセスしたときに永続的なリダイレクトが提供されるようにする必要がある状況を設定しているようです。そうでなければ、クライアントは壊れます。数年にわたって、このリダイレクトシステムは手に負えなくなる可能性があります。

この状況では、URIテンプレートを使用するREST-RPCハイブリッドアプローチよりも、サーバーがURIスペースをより細かく制御できるようにはなりませんでした。

表現のキャッシュについては多くの情報がありますが、ハイパーテキスト駆動型のRESTfulシステムでURIをキャッシュすることについてはどうでしょうか。

私は、モバイル クライアントと中央サーバーの間で RESTful Web サービスを利用するエンタープライズ システムに取り組んでいます。可能な限り RESTful としましょう。

私の質問は、HATEOAS (アプリケーション状態のエンジンとしてのハイパーメディア) と、HTTP 応答本文でのカスタム xml の使用に関するものです。

このシステムがパブリック クライアントによって使用されることは決してありませんが、各クライアントを個別に再構成することなく、サーバー側のリソース割り当てパターンを後で変更できるという HATEOAS のアイデアが気に入っています。スケーリングの問題により、サーバー機能を複数の物理ボックスに分散する必要があると判断した場合、問題ありません。これは、クライアント (またはクライアントからの指示を受けたサーバー) が新しいリソースを作成するときに生成される URI に反映されます。 .

私たちの事業領域は非常に具体的で珍しいものです。そのため、Web サービス全体で HTTP 応答エンティティ ボディにカスタム XML を使用したいと考えています。クライアントは、独自のアプリケーション状態を変更するときに使用できるリソースの場所を常に把握するために、xml からリソース URI を解析します。これがHATEAOSのH部分を「壊す」ことを私は知っています。

たとえば、クライアントが処理のためにトランザクションをサーバーに POST する場合、サーバーは次の xml フラグメントを 201 HTTP 応答本文に (より大きな xml ドキュメントの一部として) 含める場合があります。サーバーは、新しく作成されたトランザクション リソース自体の URI もクライアントに通知しますが、これはおそらく Location HTTP ヘッダーにのみ含まれます。

これはそんなに悪いことですか？このサービスを使用するクライアントがブラウザ ベースになる可能性はほとんどありません。URI を xml 内のプレーンテキストとして配信することに対するハイパーメディアの他の利点は何ですか?

XHTML を使用することもできると思いますが、モバイル プラットフォームのパーサーは POX の方がはるかに効率的です。

したがって、クライアントがHATEOASの原則に従うことを可能にする表現を提供する RESTful サービスを実装する必要があるということを、今では理解しています。理論的にはすべて理にかなっていますが、Web を精査して、アイデアに厳密に従うクライアント コードの良い例を 1 つ見つけました。

読めば読むほど、誰も実際にやっているわけではないので、これは学術的な議論のように感じ始めています! 人々は WS-* スタックの多くの欠陥について好き勝手に不満を言うことができますが、少なくともクライアントを作成する方法は明らかです。つまり、WSDL を解析してコードを生成できます。

これは、優れた RESTful サービスでは必要ないことを理解しています。関連する関係と表現について知る必要があるだけで、それらに動的に反応できる必要があります。それでも、この原則は、今までにいくつかの一般的なライブラリに抽出され、抽象化されているべきではありませんか? 受け取る可能性のある表現と関係に関する情報をフィードして、アプリケーションで使用できるより有用な高レベルのコードを取得しますか?

これらは私の中途半端なアイデアに過ぎませんが、もし私が飛び込んで適切な RESTful API を今すぐ書いたとしても、実際には誰もそれを使用できなくなるのではないかと心配しています! または、少なくともそれを使用することは、私が提供する関係と表現を解釈するために人々がグルーコードを書かなければならない余分なマイルのために、背後で非常に苦痛になるでしょう.

クライアントの観点から、これに光を当てることができる人はいますか? 私が実際に書いている聴衆のアイデアを得ることができるように、誰かが適切に動的/反応的なRESTfulクライアントコードの例を示すことができますか? (さらに、いくつかの抽象化を提供するクライアント API の例) それ以外の場合は、すべてかなり理論的です....

[編集: 注、私はここで同様の質問を見つけましたが、実際には回答されていないと思います。著者はウィキペディアのスタブを手に入れました!]

HATEOAS を使用して RESTful Web サービスを設計する際に、リンクを完全な URL (" http://server:port/application/customers/1234 ") とパスのみ ("/application/顧客/1234")?

この質問は少し長いです、ご容赦ください。RESTでは、WADLやIDLは必要ないと思います。むしろ、その概念を暗黙のうちにカバーする何か。私たち（人間）がWebを閲覧するとき、初めてWebサイトにアクセスするとき、それがどのようなサービスを提供しているかはわかりません。あなたは発見しますHTMLホームページ（またはヘルプセクションのサイトマップページ）にあるもの、またはホームページのメインメニューにあるもの。例えれば、私たち人間へのホームページまたはサイトマップは、WSDLがWS- *に対して、またはWADLがRESTサービスに対して何であるかを示しています。それだけが他のhtmlコンテンツと同じです。RESTでは、HATEOSパラダイムを尊重して、次のことが良い方法だと思います。他のリソースへのリンクを一覧表示するトップレベル（またはデフォルト）のリソースを用意します。ライブラリの例として、RestLibrary.com/と言います。次のようになります。

メディアタイプ「application/vnd.libraryml + xml」は、定義された標準、またはlibrarymlという名前の（独自の語彙である可能性があります）と想定されていることに注意してください。また、クライアントはこの「ホームページ」リソース（要素root、resource、link）を理解できる必要があります。これは、WADLの代わりに使用できる部分です。クライアントが理解できる抽象的な語彙です。たとえば、Atomのような既存の標準を使用できます。しかし、主なアイデアは、どのクライアントにも理解できる抽象的な語彙を用意することです。では、なぜWADLではないのでしょうか。まあwadlはサービスディスカバリのためだけです。ここでのアイデアは、ハイパーメディアのベースとして機能する、軽い抽象的な語彙を持つことです。「ルート」語彙。フクロウのように、owl：thing...etcがあります。クライアントが「libraryml」を知っている場合 標準では、理解できるものへのリンクをたどることができます（メディアタイプのプロパティとxmlnsを解析した後）。そうでなければ、それはしません。

RESTアーキテクチャで何かを処理する方法を理解できないとき、私は人間がWebでそれをどのように処理するかを見る傾向があります。Webには、サイトビルダーがクライアント（ユーザー）にとっての意味に関係なく、特定のコンテンツを配信できるようにするHTMLである汎用言語があります。ブラウザーは、HTMLを理解しますが、コンテンツの「意味」は理解しません。（ドメイン固有の）コンテンツを理解しているのはユーザーです。QuantumPhysics.orgと言うと、ブラウザでホームページをレンダリングでき（結局のところHTMLにすぎません）、ホームページを読むことができます。クォンタムを理解していれば、ブラウジングを続けることができます。私が出て行かない場合（私がハードウェイを学びたいのでなければ:)）

• RetsLibrary.comの例では、クライアントアプリは私と私のブラウザのようです
• QuantumPhysics.orgで。メディアタイプ「application/vnd.libraryml + xml」は量子物理学（知識）です。
• httpは両方の例でhttpです。
• 現在、QuantumPhysics.orgのHTMLはRestLibrary.comにあり、XML +その小さな抽象的な語彙（ルートリソースとリンク、Atomのようなものに置き換えることができます）です。

では、このアプローチには何か価値がありますか？ハイパーメディアと「初期URI」の概念で成功できるように、ルートの小さなハイパーボキャブラリーは必要ありませんか？

ええ 、なぜRDFをルートボキャブラリーとして使用しないのですか？

明確に定義されたRESTfulシステムでは、クライアントはルートURIまたはいくつかの既知のURIを知っているだけでよく、クライアントはこれらの初期URIを介して他のすべてのリンクを検出する必要があると言われています。私はこのアプローチの利点（分離されたクライアント）を理解していますが、私にとっての欠点は、クライアントが何かにアクセスしようとするたびにリンクを検出する必要があることです。つまり、次のリソース階層が与えられます。

「クライアントはルートURIのみを知る必要がある」アプローチに従う場合、クライアントはルートURI、つまり上記の/ collection1のみを認識し、残りのURIはハイパーメディアリンクを介してクライアントによって検出される必要があります。クライアントがGETを実行する必要があるたびに、たとえばsub1sub1sub1sub1で、クライアントが最初に/ collection1でGETを実行し、返された表現で定義されたリンクをたどってから、サブリソースでさらにいくつかのGETを実行して、必要なリソース？または、接続性についての私の理解は完全に間違っていますか？

よろしく、Suresh

HATEOAS (アプリ状態のエンジンとしてのハイパーメディア) の推奨事項は、クエリ文字列が RESTful ではないことを意味していますか?

編集：クエリ文字列は状態とあまり関係がない可能性があり、したがって質問は不可解であることが以下に示唆されました。クライアントが引数を入力しない限り、URI にクエリ文字列が含まれていても意味がないことをお勧めします。クライアントが引数を入力している場合、それはサーバー提供の URI を改ざんしていることになり、これが RESTful の原則に違反しているのではないかと思います。

編集 2: クライアントがそれを不透明なものとして扱う場合、クエリ文字列は無害に見えることに気付きました (クエリ文字列はレガシーであり、したがって便利である可能性があります)。ただし、以下の回答の 1 つで、Roy Fielding は、URI を透明にする必要があると述べていると引用されています。透明性があれば、粗悪品の使用が奨励され、HATEOAS の原則が希薄になると思います。そのような希釈は依然として HATEOAS と一致していますか? これは、REST が URI 構築のように見える密結合を必要としているかどうかという疑問を提起します。

更新この REST チュートリアルhttp://rest.elkstein.org/では、URI の構築は不適切な設計であり、RESTful ではないことが示唆されています。また、受け入れられた回答で @zoul が言ったことを繰り返します。

たとえば、「製品リスト」リクエストは製品ごとに ID を返す可能性があり、仕様ではhttp://www.acme.com/product/PRODUCT_IDを使用して追加の詳細を取得する必要があると規定されています。それは悪い設計です。むしろ、応答には各項目に実際の URL を含める必要があります: http://www.acme.com/product/001263など。はい、これは出力が大きいことを意味します。ただし、必要に応じてクライアントを新しい URL に簡単に誘導できることも意味します。

人間がこのリストを見ていて、彼/彼女が見ることができるものを望んでいない場合、「前の 10 項目」と「次の 10 項目」ボタンがあるかもしれませんが、人間がいない場合はクライアント プログラムです。 、REST のこの側面は、クライアント プログラムが使用しない可能性のあるすべての「 http://www 」のために、少し奇妙に思えます。