为访问特定订阅的当前快照，用户对 URI http://rpc.bloglines.com/getitems?s={subid} 发送一个 HTTP GET 请求，如上述 listsubs 操作的结果中所展示的， {subid} 是 Bloglines 分配的唯一订阅标志符。定义附加参数，包括(非常有趣)一个实际上违反了基本 REST 规则的参数，也就是说，它们不应该引起资源状态中的任何变化。当被提供时，参数 (n=1) 指示 Bloglines 服务将以前未读的订阅条目标记为正在读取，这实际上改变了资源状态。

　　要返回当前用户 blogroll 中未读的订阅条目的数量，用户可以向 URI http://rpc.bloglines.com/update?user={email}&ver=1 发送一个 HTTP GET 请求，这里 {email} 是用户的 email 地址，这些用户的账户应该被检查，以获得未读的订阅条目。

　　Bloglines API 参与的唯一一件事是允许有计划的访问 blogrolls 和订阅资源。API 不关心客户端访问 blogrolls 或订阅时会如何处理它们。

　　提供一个对照，与 IBM 最近实现的概念验证工程做比较来阐明 Web 服务在自动化医院患者纪录的访问、处方的编写、手术的安排等方面的用途。不做详细的说明(与客户端的非公开协议涉及的内容)，为系统建立的服务接口的集合完全集中于用户在系统中执行的活动。例如，为患者安排手续或检查，并请求检查结果的有效性等事件的异步通知。患者的档案(资源)是系统的一个很重要的方面，它通常在全部的应用程序中起到支持的作用，但不是系统的主要焦点。更确切地说，医院原型是一个面向活动的服务，这由它的 SOAP 样式 Web 服务体系结构确切的反映出来。

　　要点很简单：REST 和 SOAP 的选择归结为对您的特定应用程序的最重要部分的理解。如果您的应用程序主要集中在访问信息资源的能力(如 Bloglines 服务)，那么您用的主要是面向资源服务，并且您的应用程序应该是 REST 样式的设计模式。这里应该优先考虑 Amazon、del.icio.us、Flickr 还有其他的一些厂商(请参阅 参考资料)提供的服务 API。然而，如果您的应用程序主要集中于被执行的活动(这些活动与所依赖的资源不相关)，那么您的服务是面向活动的，并且应该利用 SOAP 样式的设计模式。

　　功能与形式

　　基于 REST 的模式的支持者常常指出它的体系结构化的简单性，并将其和 SOAP 型的 Web 服务规范的复杂性相比较，以此来说明为什么 REST 是更优越的方法。正如我已经阐明的，这一论断是有缺陷的，这两种方法要解决不同类型的问题。基于 Web 的应用程序服务，例如 Bloglines、Amazon、flikr、del.icio.us 等等，要面对不同类型的问题，这不是说说那么简单。医院需要将定制规程、编写处方的内部流程自动化，因此要求一个不同的体系结构化方法。这就是设计模式存在的原因 -- 不同的方法解决不同的问题。

　　在特定业务需求上下文之外进行比较，REST 体系结构表面上好像远不及该行业提出的各种 WS-* 规范所定义的 SOAP Web 服务体系结构复杂。而且，在某些关键地方它的功能也远没有那么强大。可靠消息是一个主要的例子。HTTP 不是一个可靠协议。这里没有使用一次且仅一次(once-and-only-once)或者重试直至成功(retry-until-success)的语义以允许可靠传输 HTTP 请求的机制。REST/HTTP 中也没有在基本 HTTP 代理机制之外进行消息路由的机制。在 REST 服务中的安全性上下文也通常局限于 HTTP 协议提供的安全机制，除非应用程序选择采用一些外部定义的安全机制(例如，一个 REST 服务实际上能返回数字签名或者加密 SOAP 消息来响应 HTTP GET 请求)。

　　对于如 Bloglines 之类的服务，这些功能限制不是关键，因为由 HTTP 提供的基本选项足以满足应用程序的需要。API 不需要：

　　可靠消息传递

　　数字签名

　　消息路由

　　资源生命周期管理

　　异步事件通知

　　由 SOAP WS-* 规范引进的其他性能

　　这并不意味着其他应用程序不要求由基于活动的方法所提供的增强功能。

　　不要理解错我的意思，所有这些在 REST 样式服务中做的事情至少从理论上讲是完全可行的。关键的问题是没有人定义过这样做的一致的标准方法。既然如此，举例来说，任何人使用任何方法在 REST 样式接口中做这样的工作(如异步事件通知或可靠消息传输)，都将会是特定于实现的一次性服务，通常不会被其它 REST 样式的服务支持。然而需要指出的更重要的问题是，通常与适合于面向资源的服务相比，这些扩展的功能更适合于面向活动的服务，因此在面向活动的 SOAP 样式服务领域里，我们见到更多的规范和更大的复杂性也就不奇怪了。