rest - 在 REST : WADL or not 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呢？ wadl 仅用于服务发现。这里的想法是拥有一个轻量级的抽象词汇，作为超媒体的基础。一个“根”词汇。就像在 owl 我们有 owl:thing...etc
现在，如果客户端知道“libraryml”标准，它可以按照链接指向它理解的内容(在解析媒体类型属性和 xmlns 之后)。如果没有，那就不会了。

当我无法理解如何处理 REST 架构中的某些内容时，我倾向于了解我们人类如何在 Web 中进行处理。在 Web 中，我们拥有 HTML 的通用语言，它使站点构建者能够交付任何特定内容，而不管其对客户端(用户)的含义如何，浏览器理解 HTML，但不理解其内容的“含义”。理解(特定领域)内容的是用户。如果我去说 QuantumPhysics.org，我的浏览器可以呈现主页(毕竟它只是 html)，我可以阅读主页。如果我了解量子，那么我可以继续浏览。如果我不这样做，我就出去(除非我想学习硬路:))

在 RetsLibrary.com 示例中
客户端应用程序就像我+我的浏览器

在 QuantumPhysics.org 上。媒体类型
“应用程序/vnd.libraryml+xml”是
量子物理学(知识)。

http 在这两个示例中都是 http。

现在 QuantumPhysics.org 的 HTML 在
RestLibrary.com 是 XML + 那个小
小抽象词汇(根
资源和链接，你可以
替换为 Atom 之类的东西)。

那么这种方法有什么值(value)吗？难道我们不需要一个根微型超词汇表，这样我们就可以通过超媒体和“初始 URI”概念取得成功吗？

编辑
是的，为什么不将 RDF 作为根词汇!

Answer 1

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

前几天，在 Mike Kelly 建议需要“超媒体应用语言”应用程序/hal+xml 之后，我们在 freenode IRC REST channel 上讨论了这种确切类型的东西

见 http://restafari.blogspot.com/2010/06/please-accept-applicationhalxml.html例如。

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