2008年10月《如何实现真正的REST风格?》

Roy Fielding查看了SocialSite的REST API,发现它并不十分符合REST风格。SocialSite的REST API最近因Roy Fielding称其不符合REST风格而受到批评。Roy说,它是众多自称符合REST风格而实则不然的系统之一。 OpenSocial的REST API是RPC式的,而且是公然宣誓其RPC本性。它在如此多的方面存在耦合,所以理应将它评为“差”。 从OpenSocial网页上提供的信息来看,你不难同意Roy的观点。例如: 在服务端为OpenSocial风格的REST和JSON-RPC提供支持在客户端为JSON-RPC批量请求提供支持服从OpenSocial对扩展的需求 另外,我们都知道REST跟RPC是紧密相关的。 鉴于已经见过很多自称符合REST风格而实则不然的网站,Roy接着就如何构建真正符合REST风格的网站(及API)给予了指导。现部分摘录如下: REST API不应依赖于某一个通信协议。如果一个协议元素(protocol element)要将URI用于标识的目的,那么它必须允许采用任意URI方案(scheme)。[做不到这一点,就意味着标识与交互没有分离。]媒 体类型(media types)是用于表示资源和推进应用状态(application state)的,REST API应将绝大部分描述精力用于定义媒体类型,或者是为现有的标准媒体类型定义扩展的关系名称(relation names)和/或基于超文本的标记(markup)。如果要就“对所谈及的URIs采用什么方法”进行定义的话,那么应完全把它放在媒体类型的处理规则 范围内进行定义(不过在大多数情况下,现有媒体类型都已经定义好了)。[做不到这一点,就意味着交互不是由超文本、而是由外部信息(out-of-band information)推进的。]REST API一定不能定义固定的资源名称或层次。服务器必须可以自由控制它自己的名称空间(namespace)。应该像HTML表单(HTML forms)和URI模版(URI templates)那样,通过媒体类型和链接关系(link relations)给出指示,使得服务器可以指导客户端如何构造正确的URIs。[做不到这一点,就意味着客户端在根据外部信息(比如跟领域相关的标准)假定资源结构——相当于面向数据方法里的RPC功能耦合。]要 使用REST API,应该只需知道初始URI(书签)和一套适合于目标用户(即可被任何使用该API的客户端所理解)的标准媒体类型。这样的话,所有的应用状态迁移, 都必须以“客户端在服务器提供的选项里挑选”这样的方式进行;服务器提供的选项,或者直接出现在用户收到的表示(representations)里,或 者在用户对那些表示进行处理后得到。客户端可以根据自己所掌握的关于媒体类型与资源通信机制的知识来决定(或限制)状态转移,客户端可以即时增加对媒体类 型与资源通信机制的支持(比如通过代码请求)。[做不到这一点,就意味着交互不是由超文本、而是由外部信息推进的。] Roy的这篇文章收到了很多反馈,有的是直接回复评论,有的是另发文章,其中有人提出了一些关于超文本/超媒体使用的问题,对此Roy回答道:[以下略]全文请看InfoQ中文站:http://www.infoq.com/cn/news/2008/10/rest-api




发表评论:
昵称:
密码:
主页:
标题:
验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)

日历 | CALENDAR

«December 2019»
1234567
891011121314
15161718192021
22232425262728
293031
blog名称:World Wide Web Watch
日志总数:193
评论数量:663
留言数量:75
访问次数:5701180
建立时间:2004年10月30日
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.030 second(s), page refreshed 144336089 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号