6

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

<root xmlns:lib="http://librarystandards.com/libraryml">
<resource class="lib:book">
  <link type="application/vnd.libraryml+xml" template="mylib.com/book/{isbn}" />
  <link type="application/vnd.libraryml+xml" rel="add" href="mylib.com/book" method="POST" />
  <link type="application/vnd.libraryml+xml" rel="update" template="mylib.com/book/{isbn}" method="PUT" />
</resource>
<resource class="lib:bookList">
  <link template="mylib.com/book?keywords={keywords}" type="application/vnd.openlibrary+xml" rel="search" />
</resource>
</root>

メディアタイプ「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をルートボキャブラリーとして使用しないのですか？

4

1 に答える 1

4

はい、私は間違いなくこのタイプのメディアタイプの必要性を理解しています。

先日、MikeKellyが「HypermediaApplicationLanguage」application/ hal + xmlの必要性を提案した後、freenodeIRCRESTチャネルでこの正確なタイプのことについて話していました。

例については、 http：//restafari.blogspot.com/2010/06/please-accept-applicationhalxml.htmlを参照してください。

RDFはこの種のことにはやり過ぎのように思えますが、間違っていることが証明されれば幸いです。RDFはHATEOASよりもリンクトデータに重点​​を置いていると思います。

于 2010-06-10T13:52:38.860 に答える