在REST:WADL或不是IDL,以下方法是正确的吗？

Question

这个问题有点长,请耐心等待.在REST中,我认为我们不应该需要WADL或任何IDL.而是隐含地涵盖其概念的东西.我想到的方式是当我们(人)上网时,当我们第一次去网站时,我们不知道它提供了什么服务.你发现了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的已定义标准或(可能只是专有词汇表).此外,客户端应该能够理解这个"主页"资源(元素根,资源和链接).这是可以用来代替WADL的部分:一个任何客户都应该理解的抽象词汇表.例如,您可以使用像Atom这样的现有标准.但主要的想法是让任何客户都能理解抽象词汇.为什么不WADL呢？well wadl仅用于服务发现.这里的想法是拥有一个轻量级的抽象词汇表,作为超媒体的基础.一个"根"词汇.就像在owl中我们有owl:thing ...等现在如果客户端知道"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作为根词汇!

Answer 1

是的，我确实看到了对这种媒体类型的需求。

前几天，在 Mike Kelly 提出需要“超媒体应用程序语言”application/hal+xml 之后，我们在 freenode IRC REST 频道上讨论了这种确切类型的事情

有关示例，请参阅http://restafari.blogspot.com/2010/06/please-accept-applicationhalxml.html 。

对于这类事情，RDF 似乎有点矫枉过正，但我​​很高兴被证明是错误的。我发现 RDF 比 HATEOAS 更关注关联数据。