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

发布于 2024-09-05 02:12:14 字数 1969 浏览 5 评论 0原文

这个问题有点长，请耐心看完。在 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:thing...等等现在，如果客户端知道“libraryml”标准，它可以跟踪它理解的内容的链接（在解析媒体类型属性和 xmlns 之后）。如果没有，那就不会。

当我无法理解如何处理 REST 架构中的某些内容时，我倾向于看看我们人类如何在 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 作为根词汇！

原文

This question is a bit long, please bear with me.
In REST, i think we should not need WADL or any IDL. But rather something that would implicitly cover its concept. The way I think about it is when we (humans) surf the Web, when we go to a web site for the first time, we don't know what services it provides. You discover those on the html home page (or a sitemap page in a help section) or maybe just the main menu on the home page. If you make an analogy, the homepage or site map to us humans is what WSDL is to WS-* or what WADL could be to a REST service. Only that its just like any other html content.
I think that in REST the following is a good way to do things, respecting the HATEOS paradigm. Have a top level (or default) resource that lists links to your other resources. For a library example, say RestLibrary.com/ it could be something like:

<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>

Note that it is assumed that the media type "application/vnd.libraryml+xml" is a defined standard or (may be just proprietary vocabulary) named libraryml. Also, the client should be able to understand this "homepage" resource (elements root, resource and link). This is the part that could be used instead of WADL : an Abstract vocabulary that should be understandable by any client. You could use an existing standard like Atom for example. But the main idea is to have an abstract vocabulary understandable by any client. Why not WADL then ? well wadl is only for service discovery. The idea here is to have an light abstract vocabulary that would serve as a base for hypermedia. A "root" vocabulary. Like in owl we have owl:thing...etc
Now if the client knows the "libraryml" standard it can follow the links to the things it understands (after parsing the media type properties and xmlns). If not, it just won't.

When i can't understand how to deal with something in REST architecture i tend to see how we Humans do it in the Web. In the Web, we have the Generic language that is HTML that enables site builders to deliver any specific content, regardless of its meaning to the client (the user), Browsers understand HTML but not the "meaning" of its content. It is the user that understands the (domain specific) content. If i go to say QuantumPhysics.org, my browser can render the home page (it is just html after all) and i can read the home page. If i understand quantum then fine i can continue browsing. If i don't i just get out (unless i want to learn the hardway :) )

In the RetsLibrary.com example the
client app is just like me+my browser
on QuantumPhysics.org. the media type
"application/vnd.libraryml+xml" is
quantum physics (knowledge).
http is http in both examples.
Now HTML of QuantumPhysics.org is in
RestLibrary.com is XML + that tiny
little abstract vocabulary (root
resource and link, that you could
replace with something like Atom).

So does this approach have any value ? don't we need a root tiny hyper-vocabulary so we can succeed with hypermedia and the "initial URI" concept ?

edit
Yeah why not RDF as the root vocabulary !

分享到QQ

分享到微博