虽然可能有一些人用REST和XML做比较,但没有竞争可比性。实际上，你也许能够把现在的大多数方法归结为下面三类：

　　1.基于简单对象访问协议（SOAP）的Web服务。

　　2.没有简单对象访问协议（SOAP）的，用XML/HTTP实现的Web服务，有或者没有正式的模式。

　　3.利用HTTP方法，MIME类型和HATEOAS（超媒体作为应用程序状态的引擎）来实现真正的REST设计风格的服务。

　　从我所看到的，有越来越多的服务被归到第2类。让其变得混淆的是，这一类几乎总是被称为RESTful服务，而在现实中，他们并不是。他们只是基于XML服务传送，使用POST HTTP操作，没有使用简单对象访问协议（SOAP）封装和网页服务描述语言（WSDL）。使用JavaScript的基于浏览器的顾客消耗这些服务比消耗基于SOAP的服务更容易。 这些服务可能还会接受使用基于JavaScript语言的轻量级的数据交换格式（JSON）/HTTP，而不是XML，甚至更简单的被基于浏览器的消费者消耗。然而，如果不是全部功能，对于大多数，他们仍然倾向于依靠POST操作。

　　基于简单对象访问协议（SOAP）Web服务的使用在企业中仍然相当普遍。为了给明确定义的接口提供优秀工具集成，许多包装产品暴露自己的服务使用了简单对象访问协议（SOAP）服务和网页服务描述语言（WSDL），但是,人们却越来越普遍地看到这些服务也公开为XML / HTTP，甚至是真正的REST风格的服务。

　　根据我的经验，第3类仍然是在是最不常见方法，至少在企业里面，但是使用有上升趋势。

　　企业服务总线（ESB）的作用

　　因此，这些趋势如何影响ESB的作用？如果有的话，对HTTP的日益重视，实际上是鼓励更多的使用基于中间件的方法。想想现在已经多少中间件存在于HTTP空间里。你能够使用高速缓存设备，负载均衡，网络安全产品，等等。真正的问题是你是否仍然需要ESB，或者你可以像大多数企业那样，使用现存的基于HTTP的中间件。

　　面临的挑战是，你越接近第三类选项，你越不可能有一个正式消息规范所。第1个选项显然已经包含WSDL文件，第2个选项可能仍然包含XML模型，但第3个选项可能除了像类似“在响应GET请求时期望什么，或者是在一个PUT或PODT中，什么HTTP参数将被接收”的开发人员文档以外，其他什么也没有。这并不妨碍使用像ESB的中间件，但它可能需要大量的工作才能完成。

　　最有可能的方案是，仍然依靠ESB系统，为落入第一和第二选项（SOAP/HTTP, XML/HTTP）而又想从第三选项得到点什么的消费者弥合差距。例如，没有理由你不能用一个拥有getOrder()操作的SOAP Web服务，然后使用ESB来公开通过一个GET请求http://rest-services/order?id=xxxxx访问的REST服务。这将ESB直接推进整合空间，在那里你想从一个没有能力做到的系统公开REST服务，而不是作为一种通用的中间件，通过所有流量。

　　因此，简而言之，我描述的三种方法中的任何一种都有放置中间件的地方。只有看到HTTP负载平衡器在基于网页的系统中的作用，才会明白。作为ESB产品，它们的作用是有可能被转移到调解需求的REST风格接口和所涉及的底层系统暴露的接口上。如果不能修改那些系统，你将需要某些中间的东西来缩小差距，ESB可能刚好合适。