WebService学习（二）——Restful

WebService学习（一）中已提到 常见的两种WebService处理方式：

1：基于WSDL / SOAP 的方式;

2：Rest 方式。

本篇中学习了解Rest方式。

一、Rest的Web Service的设计原则是基于CURD，支持四种操作：

GET-获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式；

POST-增加信息内容，显示以前的信息内容，可以看作是insert操作；

PUT-更新信息内容，相当与update；

DELETE-删除信息内容可以看作是delete。

Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的
协议了HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于
Restful的Web Service越来越多的成为首选。

二 rest是啥玩意

（1）认知
Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful
风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也
发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了满足基本的CRUD
设计原则之外，还要遵循如下约定：
1.      资源操作可以通过描述来实现即Representation
2.      消息本身是无状态与自我描述(传输支持XML与JSON)
3.      可以发送与接受多个Representation
 
Rest风格(Restful Style)架构原则：
1.      客户服务器方式
2.      无状态协议传输
3.      支持缓存
4.      统一接口定义
5.      分层系统设计
这样发布了Rest的Web服务API其改变不会影响到客户端程序与实现。如果你的系统
不能适用Rest风格的架构怎么办，重新设计一个新的架构，扩展Rest风格架构。但是
这个世界上绝大数的系统与应用要做的事情就是CRUD。
(2) 有啥好处呢

Rest消息详解:
1.      跟我们现在知道的HTTP URI没有什么分别，Google静态地图就是一个很好的例子
         只是URL加上不同参数就可以fetch不同的地图内容。
2.      可以支持任何类型的数据传输，这点与基于XML与JSON的信息传输有点同，后者
         更希望传输文本内容与结构化文本内容
3.      SOAP与XML-RPC有严格的消息格式限制，rest没有消息格式要求。客户端调用方
         便啊！
 
Rest风格Web服务的好处，显然易见一个好处就是简化了客户端的调用，不再像WSDL
那般麻烦。从而减低第三方开发者的学习成本，减短了学习曲线。有利于服务推广与普
及，吸引更多用户数量从而带来潜在的商业利益。
 
在软件即服务(SaaS - Software As A Service)与软件即平台(PasS-Platform 
As A Service)中有着重要的地位与应用。这正是那些互联网巨头对Rest风
格感兴趣的原因之一。

Rest可以用在任何
系统设计中，从本质是上Rest不是一种技术，而是一种架构原则，当然可以用来架构非
WEB的系统。系统越大风格越要象Rest方式如此才是一个成功的架构。

三 比较一下，主要还是rest火一点，拉出来66

从基本原理层次上说，REST 样式和 SOAP 样式 Web Service的区别取决于应用程序是面向资源的还是面向活动的。例如，在传统的WebService中，一个获得天气预报的webservice会暴露一个WebMethod：string GetCityWether（string city）。而RESTful WebService暴露的不是方法，而是对象（资源），通过Http GET, PUT, POST 或者 DELETE来对请求的资源进行操作。在 REST 的定义中，一个 Web Service总是使用固定的 URI 向外部世界呈现（或者说暴露）一个资源。可以说这是一种全新的思维模式：使用唯一资源定位地址 URI，加上 HTTP 请求方法从而达到对一个发布于互联网资源的唯一描述和操作。
所以我理解为rest架构定义的webservice实际上定义了一个借口的规范。
  REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。
REST的思想归结以下有如下几个关键点：

1．面向资源的接口设计

所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计，其实是RPC-REST的混合体，并非是REST的思想。

       2．抽象操作为基础的CRUD

       这点很简单，Http中的get,put,www.hbbz08.com post,delete分别对应了read,update,create,delete四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题，如果要完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。      

       3．Http是应用协议而非传输协议

       这点在后面各大网站的API分析中有很明显的体现，其实有些网站已经走到了SOAP的老路上，说是REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。

4．无状态，自包含

这点其实不仅仅是对于REST来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP的WebService也是一样。