REST与Web services

问题:你如何看待一个房间中两个或多个架构师?回答:是争论。既然SOA是如今企业中很多这样的房间中谈论的主题，那么最激烈的争论就是Representational State Transfer (REST)与Web services的关系。很多类似的讨论演变成讨论哪种方法更好，但如同SOA领域的很多争论一样，实际结果是非常微妙的。直到现在，ZapThink还是很乐意在一旁观战，但我们是时候权衡他对REST与Web services的看法了。

　　REST与Web services的上下文

　　这个持久的争论是SOA的核心挑战:创建松耦合服务接口的最好办法是什么?一种方法是称为REST的分布式计算。REST依赖于HTTP协议作为无状态的客户端/服务器协议来交换信息，它使用简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应。在REST中，资源用与Web的URL类似的URI暴露。REST的思想是改变资源的某个状态，而不是像传统分布式计算中的RPC那样调用远程系统上的某个进程

　　为了说明这一点，REST可以调用包含上百个URI的资源类型的客户。例如，http://mysite/customers/insurance/rschmelzer可以引用到某个保险应用上的我的客户的记录。为了修改该记录，用户可以POST或PUT一个XML文件到这个URI上，然后调用该URI以GET该信息。关键是REST使用的是名词，而不是动词。它没有调用某个getcustomer方法来传送customerID，而是让用户调用叫做customerID的资源，并对它抛出一个XML。

　　按照REST的观点，我们不用关心底层解决方案的架构。我们可以在n层应用或客户端/服务器解决方案中利用REST，与面向服务的方法一样简单。实际上，任何应用都可以利用REST，只要它用GET通过HTTP暴露一些功能即可。它的主要挑战在于明确并定位个体资源以及构建异步的，事件驱动风格的交互。HTTP和XML之外的REST本身的缺点也是厂商和IT公司的挑战。此外，我们还需要明确词汇的语义，即在客户端和服务器之间交换的XML的准确涵义是什么。

　　然而，在SOA中，服务并不需要映射到资源上，而是一套操作或一组业务过程。实际上，服务与功能和过程的概念映射得更紧密，所以这些功能和过程更重要。因此，服务可以暴露成资源，而资源也可以暴露成服务，而且服务和资源之间并没有谁是优先的。

　　RPC与文档风格的交互

　　真正的对比不是REST与SOA，而是REST风格的服务实现与Web services风格的特定操作。Web services并不是一种架构方法，而是一套如何定义服务(WSDL)，与服务通信(SOAP)以及发现可用服务(UDDI)的标准，还包括安全性、可靠性、组合与管理任务。服务对于代码是抽象的，因此它不表示实际代码。也就是说，我们不能运行一个服务。你只能对可能是也可能不是面向服务的底层代码暴露服务接口。由于服务不能运行，因此我们唯一关注的就是基于元数据的接口和策略，因为它们控制着服务的定义、交互和管理以及如何组合成业务过程。

　　服务也不关注资源，而是关注操作。一个服务可能有多个操作，上十个甚至上百个。每个操作都说明了一个特定的行为，让服务处理收到的XML文档并产生对应的结果。但是，此时我们遇到了挑战。我们是不是要定义一个单独的WSDL文档，来说明一个Customer Service，让它包括多个操作用于创建、修改和删除记录?我们是不是要创建多个服务，让每个服务都对应一个特定操作，而接收不同的XML文档来处理不同的用例呢?

　　这个问题是讨论Web services 中RPC风格和文档风格两种方法的核心。在RPC风格中，服务被作为具有方法的对象，它们用SOAP指明特定的操作，用特定的方法触发响应。XML消息看起来像对方法的调用，因为它具有参数和方法。例如，我们可以调用Customer service上的getCustomerName操作，传送一个像1234一样的XML文档。因此，RPC风格需要这个服务客户不仅知道他想调用的特定操作，还要知道它的方法和类型。于是，RPC是一种紧耦合方法，任何对操作或方法的改变都会引起服务客户的显著变化。

　　REST方法与RPC刚好相反，它具有名为Customer的对象，该对象拥有多种操作用于创建、删除和修改记录，也有与不同客户对应的多个独立的对象实例。因此，REST更像文档风格，它与RPC风格的不同之处在于只需要服务客户知道他们想调用的操作。在文档风格的方法中，我们只调用我们想调用的服务，并发送一个服务能处理的XML文档。因此，我们可以调用CustomerInfo service，并发送一个它能接受的XML文档。然后，服务客户将收到一个XML文档，而不用调用任何方法或指定任何数据类型。

　　于是，文档风格比RPC风格提供了更大程度的松耦合，因为任何对方法或操作的改变对服务客户的影响非常小。此外，文档风格的Web services交互的XML体包含了实际的业务消息，即有价值的信息。而在RPC方法中，XML通常只是描述了方法调用中的方法和参数。

　　因此，REST和文档风格的Web services的基本不同是服务客户把什么暴露成服务。Web services有合约，定义在WSDL中。由于Web services关注服务而不是资源，所以客户对服务中的各种操作行为有清晰的认识。而REST是面向资源的，我们只对资源有了解，而行为是隐含的，因为没有控制每个URI资源行为的合约。

　　在REST中，你可以为特定资源请求一个状态改变，但你不能指定操作。实际上，REST中的操作都是一样的:GET, PUT, POST和 DELETE.但这些操作实际上做什么(有的人称为“应用协议”)对于每个资源是不同的。如果你有面向资源的视图，且认为REST是一种架构风格，那么REST的服务就被暴露成一种资源，以确保松耦合与可组合性。而如果你在企业架构中采用面向服务的视图，那么REST就代表一种暴露服务的实现风格，它与Web service交互的文档风格同样有效。

　　ZapThink的做法

　　ZapThink认为面向服务是一种明确业务需求的方法，它用服务集合来表示复杂的可变的结合了其它服务的业务过程。于是，如何实现这些服务就是一种实现决策，它可以利用各种技术方法，包括REST和文档风格的Web services。换句话说，REST和Web services的争论是没有意义的，因为问题会归结为哪一种方法更适合工作。

　　应用REST实现松耦合服务的真正挑战在于REST没有明确的合约定义行为，即所有的行为是隐含的。REST中的数据是通过 GET, PUT或 POST来操作的，它们包含了理解服务如何行动的所有语义。因此，REST不适合那些想采用合约开发方法在松耦合之外还要利用重用和组合的组织。这正是REST的缺点，而SOA想重用的不止是资源，还包括操作和组合。

　　然而，关于Web services和REST的争论就像争论锤子和螺丝刀谁是更好的工具一样没有意义。尽管每种方法都对暴露服务和资源有着自己的价值，但SOA是在商业环境中处理不断变化的更好的方法。业务并不关心资源甚至服务本身，但是商业价值却是与这些资源和服务的交互中得到的。这取决于架构师在应用不同架构和实现风格时对于解决组织持续不断的业务变更是如何理解的。