虽然可能有一些人用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可能刚好合适。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。