Web服务的请求者和提供者之间的连接给双方都带来了大量的工作，其中包括像同意实现业务功能、认同技术合同细节这样的事情，当然还包括从服务到应用程序的宏伟计划的整合。但是，如果过于经常使用标准化的SOAP/WSDL方法，这只会使这种情况变得极度复杂。

　　还有一种办法，就是部署被称为REST的Web服务兼容架构，它代表“表述性状态转移”（Representational State Transfer）。REST是由Roy Fielding于2000年在其博士论文中所命名的一种技术。这种技术与行业中的主要规范对立竞争，虽然他是否有创造这一技术的先见之明还值得商榷，但是自从那时起，REST的简称在网络服务设计的舞台上，已经扮演了主要角色。

　　是什么使REST不同于标准化的SOAP/WSDL？是REST的简易性。它抛弃了后者必需的一些冗繁的要求，而这些要求在实现Web服务的基本功能时，在许多情况下都被证明是不必要的。

　　为了更多的了解REST的理念，让我们选取SOAP/WSDL设计中一个典型的过程：

　　1 - 提供者在现有的应用程序上创建并实现Web服务接口。

　　2 - 提供者创建WSDL契约，从而将Web服务细节提供给潜在的用户。

　　3 - 用户获取WSDL契约以便利用该契约。

　　4 - 用户在特定的平台——Java，C#，PHP，Perl——上执行WSDL，并且创建通讯程序。

　　这个过程中，最大的困难在用户身上。他不仅需要按计划提取Web服务的有效载荷——例如SOAP消息——利用其内嵌于程序做一些有用的事情，而且也需要按计划通过WSDL发出起始服务请求，以取得有效载荷。如果你像许多人一样，在不同的情况下都经历了这个过程，也许你会认为这是处理Web服务时已存在的一个事实。但是，这个过程往往能证明是不必要经历的，所以我们不如退一步，探寻Web服务的实质。

　　许多IT部门的待议事项上都有Web服务，其主要原因很简单：为了在不同系统之间实现互操作性，例如一个与Java应用程序通信的SAP ERP，或一个连接到a.NET新闻服务的PHP网站。了解了这一点，让我们分析一个非常普遍的服务——Atom和RSS新闻提要，它完全符合这一解释，而且其核心也是REST。

　　新闻摘要，最初只是在博客中的一个构想，而现在几乎在每一个主流网站上都有应用。它允许提供者发布网站更新，而且允许用户按需获取这些更新。在后台，提供者的站点可以建在Java、PHP或Perl中，同时提供一个RSS格式或Atom格式的XML有效载荷。随后，这些更新就可以被任一种语言写成的程序所使用。

　　如果你在网上迅速一瞥，就可以看到新闻摘要充斥在每个角落。有许多应用程序（用户）都从网上收集RSS数据源，从而提供丰富的内容，而这些数据源都来自第三方服务。

　　这个过程很简单，而且相比于RSS/Atom服务仅仅提供阅读功能来说，它实际上更为灵活。由于REST过程是在HTTP环境中执行，其所有的参与人员——get、post、put及delete的操作人员——都即将实现需要实现的任何商业功能。

　　如果你还是对REST理念的含义有点半信半疑，认为它更学术化，或者认为RSS和Atom新闻信息是一个孤立的情况，那么让我们再看看一些使用REST的生产型应用程序。

　　REST API允许开发人员录入众多的信息来源，从而将相同的数据整合入第三方应用程序。雅虎的Web服务产品也是基于REST建立，以至于他们目前甚至不提供SOAP支持。雅虎只使用REST。

　　看了上述几个例子，你应该能感觉到REST开发的Web服务背后有强大的社会支持，但是别急着下结论。就像所有的技术一样，REST也有其缺点。如果在REST Web服务中有一个共同论题的话，那就是它们处理的数据都具有的非必要性。

　　通过应用程序传输较为敏感的数据，如财务数据或采购信息，需要使用更先进的特性，比如业务交易，故障恢复功能和服务质量。而考虑到REST的简易性，这项工作相对来说就比较复杂。但这并不是说这一情况不能通过REST实现，而是说根据这类企业的需求，SOAP/WSDL方法更为有利，更适合他们。

　　SOAP，通过其一系列的配套规范，如WS-政策，WS-安全性，WS-可靠性和WS-业务交易管理等，清晰详细的解释了如何从问题刚出现时就解决这些问题；而在REST中，这些问题被整合进程序中，变得更为复杂。

　　虽然REST不是适用于每一种情况，但是它可以使Web服务的创建和交流工作简单很多。鉴于其在主要门户网站中广泛的应用，以及其简洁实用的方法，在探索未来Web服务设计的事业中，这是一个不得不采取的方法。