BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

REST的缺点是什么?

| 作者 Mark Little 关注 14 他的粉丝 ,译者 马国耀 关注 1 他的粉丝 发布于 2013年6月6日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

几年前,Ganesh Prasad问道,Internet比REST更基本吗?这些年,他不断围绕REST SOA、以及更时新的云计算提出相关讨论,并且钟情于REST的指导原则。然而,最近有人在LinkedIn REST架构师讨论组中的一片帖子中问道,“REST的缺点是什么?”Ganesh对此做了回复,然后又在其个人博客中重申了自己的观点

我不能说REST有“缺点”。它说到的都做到了,而且做得很好。但是,请记住REST架构的实现唯一使用的协议是HTTP。我们可以肯定地想象REST在另一种传输协议上的实现,而且其中还包含诸多方面的增强。

接着,他谈到了四个可能改进的方面。值得一提的是,Ganesh和许多人一样,将REST等同于REST/HTTP,即基于HTTP的REST:

  1. "HTTP是一个同步的请求响应式协议。这意味着它不能天然地支持服务端发起的通知(点对点),但这又是经常需要的。这就解释了为什么REST风格的应用程序中的回调需要使用应用层的设计模式,如Webhooks。现在,我们有了WebSockets这样的双向传输协议,也许工业界应该考虑在其之上根据REST原则设计一款新的应用协议。" 这一点非常有意思,因为就在差不多一年之前,我们看到有些人甚至在探讨WebSockets和REST是否能够兼容的问题。
  2. Ganesh认为,REST社区从Web Service协议栈中至少能够学到一些东西:"这些协议都是基于核心的SOAP和WS-Addressing消息机制能力之上的端到端的协议"。过去,也有人提到过类似的建议。Ganesh接着做了一个类比,他说Web Service之于WS-Addressing、WS-ReliableMessaging、WS-SecureConversation和WS-Policy好比Internet之于TCP、IP和IPSec等。Ganesh认为,REST的应用幂等性可以更好地实现可靠性(尽管并没有提到如何更好),而且可以找到REST事务的替代方案,但是他仍然留下了一个问题:
剩下的问题是安全。WS-SecureConversation和WS-Security是可路由的,它们不同于SSL/TLS,而后者却是REST唯一的安全机制。有了WS-Sec*,就可以对消息进行部分加密,留下一些明文用于基于内容的路由和分支切换。这是REST缺乏对应的优秀方案的地方。SSL是点对点的,不受代理检测,并且违反了REST原则。REST对此只能忍受。

这一说法也非常有意思,我们也看到了有的人提出了一些想法,如Resteasy的Bill Burke,他提议,REST需要更好地实现安全的方法

Ganesh继续谈到了REST对一般性QoS的问题:

REST不能支持这些一般性QoS背后的原因是,它们都需要维护“会话状态”。有状态(statefulness)存在明显的缺陷(如,影响可伸缩性和错误恢复),但是随着Redis之类的宣称常数时间(即O(1))和高性能的NoSQL存储的出现,就有可能将会话状态从内存中转移到这样的存储中,因而可支持在多个节点间共享会话,进而可以满足QoS的需要。

回到Ganesh谈到的另外两点:

  1. 他认为,HTTP的动词太少,尤其对于需要做点对点交互的场景。他建议:"INCLUDE(将资源加入到某个资源集合中并返回服务端设定的URI)、PLACE(使用客户端指定的URI向资源集合中添加资源)、REPLACE(全部替换)、FORCE(PLACE或REPLACE)、AMEND(部分更新,它是一个容器动词,为一个资源子集指定一个或多个动词)、MERGE(通过提供的表述合并部分资源)、RETIRE(比DELETE更好)和SOLICIT(替换GET,它也是一个容器动词,用于告知响应端对发起方的资源做些什么,因为现在是点对点的场景了)"
  2. "HTTP合并了应用层和传输层的状态码(如,304 Not Modified[未修改]和400 Bad Request[无效请求];407 Proxy Authentication Required[需要代理认证]和502 Bad Gateway[无效网关])。 REST在另一个协议上的实现应该更清晰地隔离应用层协议和传输层协议。HTTP承担了双份工作,因此其结果也往往不尽完美。"

参照一下HTTP 2.0的初始草案,就能发现它不可能完全采纳Ganesh的建议。然而,Ganesh本人在过去5年里好像一直致力于提出一个新规约:

我正在编写一个称作Internet Draft的新应用协议,它可以绑定任何传输(发布/订阅、异步点对点或同步请求/响应)。该协议是被我称为ROMA(面向资源/表述的消息传输架构)的新型分布式计算架构的一部分,它不仅包含数据模型和消息传输API,还包含更高级的功能(QoS、描述和流程协作)

该规约发布之后,如何解决这些已知的问题?是否能够获得REST社区的积极响应?将是很有意思的看点。


查看英文原文:What Are The Drawbacks Of REST?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT