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仅用于服务发现。这里的想法是拥有一个轻量级的抽象词汇表，作为超媒体的基础。一个“根”词汇。就像猫头鹰一样，我们有猫头鹰：东西等等现在，如果客户端知道“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建议需要“超媒体应用程序语言”应用程序/ hal + xml

之后的另一天，我们在freenode IRC REST频道上讨论了这种确切类型的事情

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

对于这类事情，RDF似乎有些过分，但我很乐意被证明是错误的。我发现RDF比HATEOAS更关注关联数据。

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

1 个答案: