代码之家 › 专栏 › 技术社区 › Hedgehog

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

rest

Hedgehog · 技术社区 · 16 年前

正如罗伊·菲尔丁所定义的那样,我正试图与其他人达成一致。最近,我一直在想:

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

转换可以由客户机对媒体类型和资源通信机制的知识决定(或限制),这两种知识都可以随时改进(例如,按需代码)。

具体来说,“资源通信机制”的知识是什么?该知识是如何在文档/规范中描述和实现的? 那么,如何最好地“即时”提高知识呢? 我想我理解“客户对媒体类型的了解”。

我有一些猜测(Put、Get等),但是我会感谢任何建议、示例或指向RESTfulAPI的指针,这些建议、示例或指针明确地解决了引用中的问题。如果这有助于我在HTTP+JSON环境中思考这些问题,我很感激REST不局限于HTTP+*。

太阳云API以前被认为是很好的休息设计,我不知道它在哪里或如何解决这些具体问题-也许是一个没有看到树木的情况?

澄清:

令我困惑的是,如果Put、Get等是这些机制,这意味着客户知道哪些机制适用于某些<媒体类型>中的特定超链接,而这似乎很脆弱,并且可能建议将超文本链接映射(直接)到资源。

1 回复 | 直到 16 年前

Darrel Miller 16 年前

通过“资源通信机制”,我相信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。这直接违反了罗伊的建议。

老实说,我只能猜测罗伊在这里指的是什么。我可以想象一个场景,在这个场景中,下载的javascript可以用于基于用户输入构建URL。这可以防止服务器必须为列表中的每个元素显式生成URL。

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

下载的代码也可以用来动态更改链接上的动词。如果你想编辑一个资源,它可以做一个GET,如果你想删除这个资源,你可以做一个删除。这将允许表示只包含一个链接,但能够执行多个操作。