在我深入探讨问题细节之前，有一点我要事先声明：REST和SOA不是相互竞争的两种集成方法。有人会马上把SOA跟SOAP关联到一起，但事实上SOA并未与任何特定技术挂钩。SOA只是一个服务结构；你选中如何让这些服务交互完全取决于你，REST当然也是选项之一。

从积极的一面来说，REST统一接口的约束之一是要求所有资源都要有一个统一资源标识符（URI）并对HTTP的GET、PUT、POST及DELETE等操作进行响应。这些操作大抵相当于数据操作的CRUD（创建、读、更新、删除）。尽管POST和UPDATE并不完全等同，但无疑可以视为如此。

为什么REST是一种好的集成方法

为什么这个是好东西？以我的经验，企业服务的绝大部分一般都是获取数据。获取数据一般不是定义一堆如getThisAndThat（…）形式的定制API，而是利用HTTP GET操作。这不是简化GET操作的使用，而是联合了GET操作与URI来实现数据获取。

URI为特定资源赋予了一个唯一的键值。如果该资源与其他资源有联系，比方说某订单与某人相关，那么URI实际上就是外键，可用于贯穿这些关系。由于REST利用了超媒体即应用状态引擎（HATEOAS），消费者只需要将URI从资源的表示中析取出来，然后执行HTTP GET即可访问到该信息。

采用HATEOAS对灵活性来说也很关键。当结构需要改变时会发生什么呢？如果对这些关系的遍历路径是通过响应中的链接来动态指定的，你的消费者未必改变。还有，如果接口定义和验证不那么严格的话，元素就可以根据需要进行添加。如果消费者关心这些，他们就会有编码变化，但任何技术都会有这种情况。

HATEOAS是非常重要，不幸的是这一点往往被忘记。许多人认为REST仅仅意味着除去SOAP封装和WSDL，这是不对的。REST并不需要像WSDL那样的接口描述语言，它完全乐意与XML、JavaScript Object Notation（JSON）等你选择的其他媒体类型一起工作。

这一点非常的强有力，因为它可以让事情变得对表示层非常的友好，无论是桌面、Web或者移动应用均如此。但仅仅拿掉WDSL和SOAP并不能给你一个REST。在那个人和订单的例子里，给一个名为<PersonID>的元素的订单返回XML并不能把它变成Restful，如果消费者无法根据该ID的值来执行HTTP GET的话。简单的XML/HTTP是不能为你带来REST的。

REST的不好之处

寻找集成方法时最大的一件事，是要认识到相对于面向功能型，REST更适合于面向资源型的。当我听到“服务”这个词时，我倾向于想到功能，我也看到过很多人有这种倾向。当我听到“资源”这个词时，我的反应会想到数据。只要你陷入到服务是更加面向功能而非面向资源这种观念时，要想想确定如何将其以REST的方法表现出来就变得很棘手。

比方说，什么才是暴露计算逻辑的合适方法？在更为面向功能的模式里，如SOAP，你可能会创建一个计算操作。而在REST，合适的方法有可能是聚焦于获取计算结果值上面，比如 GET/order/12/price。尽管这个问题很容易解决，但是实际上你可能会遭遇到更具挑战性的情况。此外，面向资源模式意味着你必须创建那一种固定的资源模型。这并非易事。当然，这两种模型都不需要一个固定的功能模型。

REST的另一项挑战是它会导致一种更为精细的模式。你什么时候会在你的响应中提供链接？又会在什么时候在关系中弹出实际数据？就积极的一面而言，这是你可以做出的设计选择。这并不是说你不能返回一个让人点击的链接，同样你返回数据本身也可以。你可以这么认为，把它当作执行一个join，但同时也返回外键，这样的话就可以获得更多的数据。

最后，尽管REST的简单性相当吸引人，但也意味着创建支持的工具会更有挑战些。如果你考虑SOAP或基于XML服务相关的工具化，有WSDL或XSD（或二者）对于使能这些工具很关键。

有了REST，这就是另一个故事。肯定有一些工具可以采取POJO或关系式的模式，然后通过REST来暴露它。同样地，为由RESTful服务返回的XML表示定义XML schema，然后利用类似JAXB的东西来转化为Java也不是不可以。只是你要意识到，靠这些文件，尤其是如果该schema在运行时才利用时，会制造额外的约束，有可能令对变化的支持更加昂贵。

总的来说，我对该问题以原本的方式来提出而非SOAP与REST之争感到高兴。像这样的决定，总会既有优点也有缺点，没有绝对。任何在IT工作的人都不会缺少对方案的宗教信仰，任何一种方案都会有许多成功和失败的例子。把这些方案的优缺点跟你所在组织的优缺点进行匹配会更重要。