浅谈WebService技术以及实现相关的REST和SOAP
前言：今天工作用到了REST接口，网上查找发现了许多写REST和SOAP的文章，所以又联想到了前段时间刚用过的WebService技术就是用SOAP实现的，然后就花了些时间搞了一下WebService原理以及REST和SOAP的区别。
WebService实现原理:
一、Web Service基本概念
Web Service也叫XML Web Service是一种可以接收从Internet或者Intranet上的其他系统中传递过来的请求，轻量级的独立的通讯技术。WebService有两种方式，一是SOAP方式，二是REST方式。SOAP实现是基于XML的交互，WSDL也是一个XML文档，可以使用WSDL作为SOAP的描述文件；REST实现是支持JSON、XML等的交互，不需要WSDL。
二、Web Service实现方式
WSDL：(Web Services Description Language)WSDL文件是一个XML文档，用于说明一组SOAP消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。
UDDI(Universal Description, Discovery, and Integration)是一个主要针对Web服务供应商和使用者的新项目。在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件，UDDI是一种根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制(标准的XML/HTTP)来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。
具体实现过程
1)、Web服务提供者设计实现Web服务，并将调试正确后的Web服务发布到UDDI注册中心进行注册。(爱心提示:我在描述Web服务中介和UDDI注册中心其实都是指UDDI，他们是一个东西，我开始就被网上一些文章给弄迷糊了。)；(发布)
2)、Web服务请求者向服务注册中心UDDI请求特定的服务，服务注册中心为请求者寻找满足请求的服务；(发现)
3)、服务注册中心向服务请求者返回满足条件的Web服务描述信息WSDL,各种支持Web服务的机器都能阅读；(发现)
4)、利用从Web服务注册中心反悔的描述信息生成对应的SOAP消息，发送给Web服务提供者，以实现Web服务的调用;(绑定)
5)、Web服务提供者按SOAP消息执行相应的Web服务，并将服务结果返回给Web服务请求者。(绑定)
REST实现方式
REST其实并不是什么协议也不是什么标准，而是将Http协议设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。
由于REST实现WebService的方式没有具体去试过，所以暂且保留先不总结，待使用过后再进行补充。
REST与SOAP的区别:
什么是SOAP?
SOAP是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML的数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值、和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API,即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL(Web Servie Description Language)也遵循XML格式，用来描述哪个服务器提供一条什么服务，怎么找到它，怎么找到它，以及该服务使用怎么的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送就使用HTTP的POST方法。
什么是REST?
REST（Representational State Transfort）形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。REST应该满足这样的特点：1)客户端和服务器结构；2)连接协议具有无状态性(即是HTTP协议);3)能够利用Cache机制增进性能；4)层次化的系统；说到底，REST只是一种架构风格，而不是协议或标准。但这种新风格对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，因为它面向资源，甚至连服务也抽象成资源，因为它和HTTP紧密结合，因为它服务器无状态。
REST的优点
REST简单而直观，把HTTP协议利用到了极限，在这种思想指导下，它甚至用HTTP请求的头信息来指明资源的表现形式(如果一个资源有多种形式的话，例如人类友善的页面还是机器可读的数据?),用HTTP的错误机制来返回访问资源的错误。由此带来的直接好处是构建的成本减少了，例如用URI定位每一个资源可以利用通用成熟的技术，而不用在服务器端开发一套资源访问机制。又如只需简单配置服务器就能规定资源的访问权限，例如通过禁止非GET访问把资源设成只读。
服务器无状态带来了更多额外好处，因为每次请求都包含响应需要的所有信息，所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来。而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置，而不需要考虑状态信息。更多的缓存也变成可能，而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应。总体结果是，网络的容错性和延展性都增强了，这些本来是WEB设计的初衷，日趋复杂和定制的WEB把它们破坏了，现在REST又返璞归真，试图把Web Service带回简单的原则中来。
REST是万能的吗？
但是REST就是万能的吗？无状态带来了巨大的优势，同时也带来了难以解决的问题，例如，怎样授权用户才能使用的服务？怎样验证用户身份？如果坚持服务器无状态，也就是不记录用户登录状态，势必要求每一次服务请求都包含完整的用户身份和验证信息。在这种情况下，怎样避免冒认？怎样避免用户信息泄露？事实上，构建REST的安全机制已经在讨论中，其结果无非导致另一个SOAP:复杂的需求摧残了易用性。
REST的支持者声称REST的请求和应答数据简单可读，而SOAP则需要一系列繁琐的封装；即使如此，SOAP仍然不能达到接口的一致性，不同的厂商有各自的接口，而REST只使用HTTP定义的方法，因此是通用的。事实确实如此吗？试想用REST实现两数求和的服务（此处是加法）作为一个资源，参数（此处是两个加数）作为请求的参数，结果以XML或JSON语法返回，是否比SOAP更简单易用？通用接口仍然没法达到，因为资源的名称、参数的名称、结果的格式仍然是服务提供者定义的。为了解决这个问题，提出了WASL(Web Application Description Language)来描述REST接口。WADL就像是WSDL的REST版，随着REST被应用到复杂的领域，SOAP的影子无处不在。
面向资源和面向事务
REST在面向资源的应用中左右逢源，但在面向事务的应用中却未如人意。面向资源的应用操作简单，无非创建、读取、改变、删除几项，但是面向事务的应用不允许用户直接操作资源，用户只需向系统提交一个事务说明要求，然后等待事务的完成，就如一个网上银行的用户不直接修改账户和存款，而是提交一个事务告诉银行自己要转账。如果把这样的服务看成一种资源，通过向资源发送POST请求完成事务，那不过是SOAP的翻版而已，无论是这样，还是通过PUT来创建事务，都改变了系统的状态(资源本身未改变，此处是改变了用户的余额),显然违背了REST直观的初衷。
事实上，一些Web Service提供者提供的REST API只有REST的外壳，传输的请求和应答全然是简化了的SOAP,这种新瓶装旧酒的做法只是加深了标准的分歧而已。归根结底REST无法简单地解决一些应用，因此我们只能看到SOAP在REST外壳下的借尸还魂。没有一项技术能够一劳永逸地解决所有问题，只需要在预定的约束下优美地解决所在领域的问题就足够了。一项新技术推出的时候总是引来无数的跟风和吹捧，只有当尘埃落定之后才能得到中肯的评价。