《基于REST架构的Web Service设计课件》由会员分享，可在线阅读，更多相关《基于REST架构的Web Service设计课件（23页珍藏版）》请在金锄头文库上搜索。
1、基于Rest架构的Web Service,什么是Rest,Rest是英文Representational State Transfer的缩写，中文翻译：表述性状态转移。 Rest本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。 Rest架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。 基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规范的基础上增加新的规范， 就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风
2、格。,Rest的Web Service设计方式,Rest资源设计,资源,URI规范(RFC 2396)指出： “资源可以是任何有标示的东西”； “并非所有的资源都是通过网络能够获取的”。 任何事物，只要有被引用的必要，就是一个资源(resource)。它可以是一个实物，也可以是一个抽象的概念。 通常一个资源是某个可以存放在计算机上并体现为比特流的事物。在Web中，可以这样认为资源是URI标示的东西。,表示,资源和表示不是一码事。Web上获取的不是资源，而是资源的表示。 对于给定的资源，可以有很多不同的表示。,REST设计准则,Rest的优点,Rest的基本模式,对一个资源的操作分为四种：Cre
3、ate（创建）、Read（读取）、Update（更新）和Delete（删除）；更新 向URL 发送删除 向URL 发送 DELETE 请求查看 向URL 发送 GET 请求创建新的博贴 向URL 或者 (直接写ID，这种一般很少见) 发送 POST 请求,Xml形式测试用例,Json形式测试用例,Rest和Soap Web Service的比较,成熟度 效率和易用性 安全性 应用设计与改造,成熟度,SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通（在部
4、分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正） REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。 由于没有
5、类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。 总的来说SOAP在成熟度上优于REST。,什么是SOAP,SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增
6、长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数
7、情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。,效率和易用性,SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。 REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发
8、者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。 因此在效率和易用性上来说，REST更胜一筹。,安全性,这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全已经被提到了很高的高度，特别是作为外部接口给第三方调用，安全性可能会高过业务逻辑本身。 SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Securi
9、ty来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。 REST没有任何规范对于安全方面作说明，同时现在开放REST风格API的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，其实是直接采用了XML-Security和XML-Signature，
10、效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范，是未知的，但是加入的越多，REST失去它高效性的优势越多。,应用设计与改造,我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。 而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。,结束语,技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。 REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。,
