观点：REST在SOA中适合哪个位置？

自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总结说：

架构风格（及架构模式）是你能用来解决挑战的工具。锤子可以被很好地用到很多场合，但是，最好是确保工具箱中不是只有锤子。