Bloglines API 最近的发布引发了又一轮关于是使用 REpresentational State Transfer(REST)还是使用简单对象访问协议(Simple Object Access Protocol，SOAP)Web 服务的讨论。然而与一些人所认为的相反，这些不同的面向服务体系结构(Service-Oriented Architecture，SOA)设计模式不是互斥的。也不是说一个就比另外一个优越。对于不同的应用场景，它们每一个都有自己相对的优势和劣势，并且它们都是解决实际客户的实际问题的有效方法。诀窍就在于能够决定采用哪一种方法。答案可能比您想象的更简单。

　　每当一些 Web 应用服务提供方提出允许开发者集成他们的服务的 Web 服务 API 时，大家都非常关心由 API 实现的互操作设计模式。如果 API 使用的是 REST 样式的互操作，REST 方法的拥护者就会将该 API 作为说明为什么 REST 样式服务比 SOAP 样式服务更优越的重要例子而加以称赞;同样地，如果 API 使用 SOAP 样式 Web 服务模式，情况也类似。似乎很少有人关心这样的一个事实，模式的选择主要取决于正在被执行的应用程序的类型，并且像所有优秀的体系结构决策一样，开发者应该将他们的选择基于正在被开发的应用程序的特定技术需求和特性，而不是基于针对单一体系结构方法的一些特殊偏好。

　　资源还是活动?

　　从基本原理层次上说，REST 样式和 SOAP 样式 Web 服务的区别取决于应用程序是面向 资源的还是面向 活动的。

　　面向资源服务集中于明确的数据对象，一些基本、标准的操作可以依据这些数据对象而执行。如权威的 Gang of Four(GoF) 设计模式这本书所述，对于熟悉面向对象设计模式概念的开发者来说，面向资源服务与基本 Memento 模式类似。实际上，服务提供方维护一组资源，并且公开一组基本操作来执行以下任务：

　　检索资源

　　修改资源

　　创建新资源

　　删除资源

　　根据定义，REST 样式 Web 服务是面向资源的服务。您可以通过统一资源标识符(Universal Resource Identifier，URI)来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作包括：

　　GET - 该操作返回已标识资源的状态表示。您可以通过大量的上下文要素来确定状态，例如谁正在提交请求、操作的参数(传入的参数如 HTTP 头或者查询字符串参数)和服务提供方维护的当前会话状态。

　　POST - 该操作执行对已标识资源的一些特定于应用程序形式的更新。该操作行为完全依赖于实现它的服务。由该操作返回的数据也完全依赖于应用程序。举例来说，像 GET 操作一样，它可以返回一个状态表示，它还可以选择根本不返回任何数据。

　　PUT - 该操作在已标识位置(URI)创建新资源。操作输入必须包括一个资源的状态表示。它完全依赖服务来创建基于这个状态表示的资源。

　　DELETE - DELETE 操作销毁已标识位置(URI)的资源。

　　在许多方面，REST 样式 Web 服务与 SQL、元组空间(tuple spaces)、简单消息列队等技术相似。它们都使用普通的简单操作针对明确的资源起作用。

　　SQL - SELECT、INSERT、DELETE、UPDATE 等

　　元组空间 - GET、PUT

　　消息列队 - SEND、RECEIVE

　　在每一个案例中，服务接口的设计允许您移动关于资源的信息，让其依赖于请求方来指出希望通过这些信息来做什么。