rest - REST的“资源通信机制”和“即时”改进了客户对它们的了解

我正在尝试与Roy一起达成协议，正如Roy Fielding所定义的那样。最近我一直试图把我的想法包围起来：

我感兴趣的概念在这句话中：

转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以在运行中进行改进（例如，按需代码）。

具体来说，什么是“资源沟通机制”的知识，这些知识如何在文档/规范中描述并在实现中实现？那么，如何最好地“即时”改善这些知识？我想我理解“客户对媒体类型的了解”。

我有一些猜测（PUT，GET等），但我会很感激RESTful API的任何建议，示例或指示，明确地解决了该引文中的问题。如果它有助于我在HTTP + JSON的上下文中考虑这些问题，我感谢REST不仅限于HTTP + *。

Sun Cloud API以前被认为是一个很好的RESTful设计，我无法看到它在哪里或如何解决这些特定问题 - 也许是没有看到树木的情况？

澄清：

让我感到困惑的是PUT，GET等。是这些机制，这表明客户端知道哪些应用于某些＆lt; media-type＆gt;中的特定超链接，这似乎很脆弱，并且可能建议超文本链接（直接）映射到资源。

通过“资源通信机制”，我认为Roy指的是HTTP请求和HTTP动词。他只是在没有指定HTTP的情况下说它，因为REST不依赖于HTTP。我想说，对于99.99％的REST服务，资源通信机制记录在RFC2616中。

Sun Cloud API满足这些要求，因为客户需要了解使用API的方法是如何执行HTTP请求以及返回的媒体类型的语义。例如，如果客户端不理解类型为application/vnd.com.sun.cloud.Cloud+json的文档中包含的内容，则它将无法使用该API。

这与OData和SData等未定义新媒体类型的服务形成鲜明对比，但假设客户端知道如何从Atom订阅源中提取域数据并期望客户端根据定义URI空间的一组规则构造URL。这直接违反了Roy的建议。

老实说，我只能猜测罗伊在这里提到的是什么。我可以想象下载的javascript可以用于根据用户输入构建url的场景。这可能会阻止服务器为列表中的每个元素显式生成URL。

此外，可以根据用户输入动态启用或禁用某些有效转换。考虑在用户输入所有必填字段之前您不想启用提交按钮的情况。检索到的文档包含允许转换的链接，但下载的代码控制用户何时以及是否可以选择链接。

下载的代码也可用于动态更改链接上的动词。如果您想编辑资源，它可以执行GET，如果要删除该资源，则执行DELETE。这将允许表示仅包含单个链接，但能够执行多个操作。