自 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 总结说：
架构风格（及架构模式）是你能用来解决挑战的工具。锤子可以被很好地用到很多场合，但是，最好是确保工具箱中不是只有锤子。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论