概念吓死人的webservice

前倾提要：这是我七拼八凑，自己用手打出来的头一篇了！都是别人的想法，我抄袭的，我坦白，我这只是总结一下觉得有用的

本来题目想叫（1）REST API 和WebService（2）REST 样式和 SOAP 样式 （3） SOAP Webservice和RESTful Webservice

我感觉就是概念，可能理解不深入，rest方式，restful风格，称谓太多了。

简单说   WebService 就是一个服务 ，别的程序能访问并使用这项在线服务。（提供服务和wsdl,调用解析你来搞）
api  就相当于一个别人编译好的类，你直接引用后使用（提供接口和服务，调用返回简单点）

引用有。。。很多，暂不列了

一 认知

常见的两种Web Service处理方式为：a.      基于WSDL/SOAP的方式b.      Rest方式方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可以使用。它不是我要说的重点，基本调用流程如下：

方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分别为：GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作PUT – 更新信息内容，相当与updateDELETE – 删除信息内容可以看作是delete

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

二 rest是啥玩意

（1）认知Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了满足基本的CRUD设计原则之外，还要遵循如下约定：1.      资源操作可以通过描述来实现即Representation2.      消息本身是无状态与自我描述(传输支持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也是一样。

四   好，看完基础了，在深入一下，看看别人写的，更好比如http://www.cnblogs.com/thiaoqueen/p/7143797.html　　　http://www.cnblogs.com/anruy/p/5946741.html