Web Service - RESTful 和 SOAP 笔记

1.什么是Web Service（Web服务）

从表面上看，Web Service就是一个应用程序，它向外界暴露出一个可以经过Web进行调用的API。

这就是说，你可以用编程的方法透明的调用这个应用程序，不须要了解 它的任何细节，

跟你使用的编程语言也没有关系。

例如能够建立一个提供天气预报的Web Service，那么不管你用哪一种编程语言开发的应用，均可以经过调用它的API并传入城市信息来得到该城市的天气预报。

之因此称之为Web Service，是由于它基于HTTP协议传输数据，

这使得运行在不一样机器上的不一样应用无须借助附加的、专门的第三方软件或硬件，

就可相互交换数据或集 成。

2.SOA（Service-Oriented Architecture，面向服务的架构）

SOA是一种思想，它将应用程序的不一样功能单元经过中立的契约联系起来，

    独立于硬件平台、操做系统和编程语言，使得各类形式的功能单元可以更好的集成。

    显然，Web Service是SOA的一种较好的解决方案，它更多的是一种标准，而不是一种具体的技术。

3.概念解释：SOAP、WSDL、UDDI

SOAP	简单对象访问协议（Simple   Object Access Protocol）， 是Web   Service中交换数据的一种协议规范。
WSDL	Web服务描述语言（Web   Service Description Language）， 它描述了Web服务的公共接口。 这是一个基于XML的关于如何与Web服务通信和使用的服务描述； 也就是描述与目录中列出的Web服 务进行交互时须要绑定的协议和信息格式。 一般采用抽象语言描述该服务支持的操做和信息， 使用的时候再将实际的网络协议和信息格式绑定给该服务。
UDDI	统一描述、发现和集成（Universal   Description, Discovery and Integration）， 它是一个基于XML的跨平台的描述规范， 可使世界范围内的企业在互联网上发布本身所提供的服务。 简单的说，UDDI是访问各 种WSDL的一个门面（能够参考设计模式中的门面模式）。

4.Java规范中和Web Service相关的规范有哪些

Java规范中和Web Service相关的有三个

JAX-WS(JSR 224)	这个规范是早期的基于SOAP的Web   Service规范JAX-RPC的替代版本， 它并不提供向下兼容性， 由于RPC样式的WSDL以及相关的API已经在Java   EE5中被移除了。 WS-MetaData是JAX-WS的依赖规范， 提供了基于注解配置Web   Service和SOAP消息的相关API。
JAXM(JSR 67)	定义了发送和接收消息所需的API,至关于Web   Service的服务器端
JAX-RS(JSR 311 & JSR 339 & JSR 370)	是针对REST（Representation   State Transfer）架构风格制定的一套Web Service规范。   REST是一种软件架构模式，是一种风格，           它不像SOAP那样自己承载着一种消息协议，           能够将REST视为基于HTTP协议的软件架构。 REST中最重要的两个概念是资源定位和资源操做，           而HTTP协议刚好完整的提供了这两个点。           HTTP协议中的URI能够完成资源定位，           而GET、POST、OPTION、DELETE方法能够完成资源操做。   所以REST彻底依赖HTTP协议就能够完成Web   Service，           而不像SOAP协议那样只利用了HTTP的传输特性，           定位和操做都是由SOAP协议自身完成的，           也正是因为SOAP消息的存在使得基于SOAP的Web   Service显得笨重逐渐被淘汰。

5.REST和SOAP Web Service的比较

5.1什么是SOAP?

                SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，

用于在Web Service中，把远程调用和返回封装成机器可读的格式化数据。

事实上SOAP数据使用XML数据格式，

定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。

并且随着须要的增加，又不得增长协议以支持安全性，

这使SOAP变得异常庞大，背离了简单的初衷。
另外一方面，各个服务器均可以基于这个协议推出本身的API，

即便它们提供的服务及其类似，定义的API也不尽相同，这又致使了WSDL的诞生。

WSDL (Web Service Description Language) 也遵循XML格式，

用来描述哪一个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，

简言之，服务发现。

如今，使用Web Service的过程变成，

得到该服务的WSDL描述，

根据WSDL构造一条格式化的SOAP请求发送给服务器，

而后接收一条一样SOAP格式的应答，

最后根据先前的WSDL解码数据。

绝大多数状况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

5.2什么是REST？

REST (REpresentational State Transfort)，

形式上应该表述为客户端经过申请资源来实现状态的转换，

在这个角度，系统能够当作一台虚拟的状态机。

REST应该知足这样的特色：

1)客户端和服务器结构；

2)链接协议具备无状态性；

3)可以利用Cache机制增进性能；

4)层次化的系统；

5)按需代码。

说到底，REST只是一种架构风格，而不是协议或标准。

但这种风格对现有的以SOAP为表明的Web Service形成的冲击也是革命性的，

由于它面向资源，甚至连服务也抽象成资源，

由于它和HTTP紧密结合，由于它服务器无状态。

5.3REST与SOAP的区别？

即便绝大多数SOAP是运行在HTTP上，使用URI标识服务，

SOAP也仅仅使用POST方法发送请求，用一个惟一的URI标识服务的入口。
      对于SOAP，delete操做也要用POST方法来发送，

而其实HTTP协议有更合逻辑的DELETE方法可用。

REST为每个资源指定一个惟一的URI，
                而用HTTP的4种方法GET、POST、PUT、DELETE直观地表示
                                获取、建立、更新和删除图书。

REST的优势?
                REST简单而直观，把HTTP协议利用到了极限。
                                1. 它用HTTP请求的头信息来指明资源的表示形式，
                                2. 用HTTP的错误机制来返回访问资源的错误。
                                                由此带来的直接好处是构建的成本减小了，
                                                例如用URI定位每个资源能够利用通用成熟的技术，
                                                而不用再在服务器端开发一套资源访问机制。
                                3. 只需简单配置服务器就能规定资源的访问权限，
                                                例如经过禁止非GET访问把资源设成只读。
                                4. 服务器无状态带来了更多额外好处，
                                                由于每次请求都包含响应须要的全部信息，全部状态信息都存储在客户端，
                                                服务器的内存从庞大的状态信息中解放出来。
                                                并且如今即便一台服务器忽然死机对客户的影响也微乎其微，
                                                由于另外一台服务器能够立刻代替它的位置，而不须要考虑恢复状态信息。
                                5. 更多的缓存也变成可能，
                                                而以前因为服务器有状态，对同一个URI的请求可能致使彻底不一样的响应。
                整体结果是，网络的容错性和延展性都加强了，这些原本是WEB设计的初衷，
                                日趋复杂和定制的WEB把它们破坏了，如今REST又返璞归真，
                                试图把Web Service带回简单的原则中来。
REST的不足之处？
                无状态带来了巨大的优点，同时也带来了难以解决的问题，
                                例如，怎样受权特定用户才能使用的服务？怎样验证用户身份？
                                若是坚持服务器无状态，也就是不记录用户登陆状态，
                                势必要求每一次服务请求都包含完整的用户身份和验证信息。
                                在这种状况下，怎样避免冒认？怎样避免用户信息泄漏？
                                事实上，构建REST附属的安 全机制已经在讨论中，
                                其结果无非致使另外一个SOAP：复杂的需求摧残了易用性。
      REST在面向资源的应用中左右逢源，但在面向事务的应用中却未如人意。
            面向资源的应用操做简单，无非建立、读取、改变、删除几项，
                                可是面向事务的应用不容许用户直接操做资源，
                                用户只需向系统提交一个事务说明要求，而后等待事 务的完成，
                                                就如一个网上银行的用户不直接修改帐户和存款，
                                                而是提交一个事务告诉银行本身要转帐。
                                                若是把这样的服务当作一种资源，
                                                                经过向资源发送POST请 求完成事务，那不过是SOAP的翻版而已。
                                                不管是这样，仍是经过PUT来建立事务，
                                                                都改变了系统的状态（资源自己未改变，此处是改变了用户的余额），
                                                                显然 违背了REST直观的初衷。