自 REST 面世以来,它就一直被无数口水所包围。各色人等纷纷现身说法,为各自的阵营摇旗呐喊。但不管怎样,REST 终究还是站稳了脚跟。而且在各种争论之中,人们慢慢地得到了一个较为清晰的看法。
最近,Jean-Jacques Dubray 就 REST 在 SOA 中适合什么位置发表了自己的看法,JJ 本人也是 InfoQ 的编辑之一。他认为,并非所有的 REST 特性都适合 SOA,并列出了他认为应该使用的那些:
- URI:唯一的(而不是统一的)资源标识符
- 针对基于角色访问的内容协商
- GET,幂等性且无副作用(不要 PUT、POST 或 DELETE)
- 恰当地使用缓存(不要为实例进行状态轮询)
在该贴的回复中,Subbu Allamaraju 对没有提到“统一接口”表示惊讶。对此,JJ 回应说,他确实提到了“统一接口”,但只是其中的“GET”方法。他还进一步表示,对于 互联系统来说,“每个资源一个端点(one-endpoint-per-resource)”模型是一个有缺陷的模型。
他评论说:
……“面向资源”这个概念有价值吗?有,简直是无价之宝。每个人都应该了解 REST。是的,有许多面向资源的模式也可以在互联系统中被使用。 HTTP 作为中间件有价值吗?没有,它是构建互联系统的灾难。它非常适合“浏览器到服务器”的交互。毫无疑问,对于“服务器到服务器”的交互,它则完全是个祸害。 并且一个原因就是,它造成了对一个端点(或每个资源多个端点)的需要。遗憾的是,它不仅仅是 URI,换句话说,在代码中的某处要有一个东西来“侦听”那个 特殊的 URI。
此外,JJ 认为,资源的概念虽然是 SOA 的核心,但是服务同样重要,并且两者是互补的。单单只提及一方并不足以构建互联系统。而且,他还在文中对 “云计算是 RESTful”的观点进行了批驳了,并表现出对“面向资源编程模型(Resource Oriented Programming Model)”的不以为然。
他写道:
……每个信息系统都有两个维度:数据和流程。流程控制数据的状态,数据当然能并且必须在流程的边界外可被访问。至今为止,大多数 的编程模型(MVC、ASP/JSP……)都完全假设,流程这个维度是没用的,因为它可以通过 CRUD 实现。REST 也做了相同的假设。Roy 针对 Web 做这样的假设没错,但针对云计算或企业 SOA 再做这样的假设就不对了(否则,它就看起来象 Web 了)。
这一观点在 Arnon Rotem-Gal-Oz 那儿得到了回应。 他认为,尽管就单个服务而言,REST 非常适合,但是涉及多个服务之间的协调时,REST 就不太擅长了。其间,他建议结合事件驱动架构(EDA)引入业务 事件,或使用一些外部实体来对服务进行编排(choreograph)或编配(orchestrate),如 BPM。他说道:
在我的组织中,我们有大量的流程给事件处理提供帮助,其效果要比 REST over HTTP 好得多。
针对何时使用哪种架构风格,Arnon Rotem-Gal-Oz 总结说:
架构风格(及架构模式)是你能用来解决挑战的工具。锤子可以被很好地用到很多场合,但是,最好是确保工具箱中不是只有锤子。
评论