白话REST-识别真假REST

转自：http://blog.csdn.net/ugg/article/details/9026649
php

你们对REST的认识？html

谈到REST你们的第一印象就是经过http协议的GET,POST,DELETE,PUT方法实现对url资源的CRUD（建立、读取、更新和删除）操做。好比
http://www.aizher.com/c2/（读取）
仍然保持为 [GET] http://www.aizher.com/c2/
http://www.aizher.com/c2/create（建立）
改成 [POST] http://www.aizher.com/c2/
http://www.aizher.com/c2/update（更新）
改成 [PUT] http://www.aizher.com/c2/
http://www.aizher.com/c2/delete（删除）
改成 [DELETE] http://www.aizher.com/c2/
这种形式的REST只是CRUD（增删改查），从这个层面上，好像REST只是和RPC一个层面的东西，没有什么了不得，其实这些都是对REST误读。也误导你们实现REST时，特种注重GET,POST,PUT,DELETE方法的处理，包括一些所谓的REST框架，好比JBoss RESTEasy，Restlet Tomcat。究其缘由是， REST提供了一组架构约束，看成为一个总体来应用时，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减小交互延迟、加强安全性、封装遗留系统的中间组件。其实从整个REST推导过程当中能够了解到，REST没有说起HTTP协议的任何方法，只是后期你们从REST的统一接口中扩展出这些操做概念。前端

到底什么是REST？
         REST是中文翻译为表征状态转移（英文：Representational State Transfer）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。从字面意思来讲，“表述”是很难理解是什么东西的？从论文上咱们能够看到表述，通常指HTML文档（包括json，xml等），jpeg等图片资源。
         先从理论层次上咱们看一下REST是怎么推导来的（参考论文第五章）
         Web架构背后的设计基本原理，可以被描述为由一组应用于架构中元素之上的约束组成的架构风格。当将每一个约束添加到进化中的风格时，会产生一些影响。经过检查这些影响，咱们就可以识别出Web的约束所致使的属性。而后就可以应用额外的约束来造成一种新的架构风格，这种风格可以更好地反映出现代Web架构所期待的属性。经过简述REST做为架构风格的推导过程，后面各节将会详细描述组成REST风格的各类特定约束
        1：从“空”风格开始。从架构的观点来看，空风格描述了一个组件之间没有明显边界的系统，这就是咱们描述REST的起点。
        2：客户-服务器。客户-服务器约束背后的原则是分离关注点。经过分离用户接口和数据存储这两个关注点，咱们改善了用户接口跨多个平台的可移植性；同时经过简化服务器组件，改善了系统的可伸缩性。
        3：无状态。这个约束致使了可见性、可靠性和可伸缩性三个架构属性，可是无状态并非没有缺点的，无状态增长了在一系列请求中发送的重复数据（每次交互的开销），可能会下降网络性，正由于这个缺点，因此在REST风格中增长了缓存的考虑。
        4：缓存，添加缓存约束的好处在于，它们有可能部分或所有消除一些交互，从而经过减小一系列交互的平均延迟时间，来提升效率、可伸缩性和用户可觉察的性能。可是缓存仍是有缺点的，若是缓存中陈旧的数据与将请求直接发送到服务器获得的数据差异很大，那么缓存会下降可靠性。注意这里的缓存并非指MC，redis之类的缓存，而是在网络代理中，好比proxy服务器上的缓存机制。
         5：统一接口。使REST架构风格区别于其余基于网络的架构风格的核心特征是，它强调组件之间要有一个统一的接口，为了得到统一的接口，须要有多个架构约束来指导组件的行为。REST由四个接口约束来定义：资源的识别（identification ofresources）、经过表述对资源执行的操做、自描述的消息（self-descriptive messages）、以及做为应用状态引擎的超媒体相关因素REST和其余概念关系。统一接口的虽然晦涩，可是它是REST风格核心特征，也是前面咱们讨论经过CURD方式操做资源的一种表现，也是咱们最容易接触感觉到的一层，后面淘宝，微博，微信开放平台的开放接口，其实就是咱们接触这个平台的统一接口，评价一个开发平台是否REST的标准，也在于这个平台的设计者对统一接口的理解。
         6：，分层系统，分红系统风格经过限制组件的行为（即，每一个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。经过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，而且提升了底层独立性。分层系统增长了数据处理的开销和延迟，所以下降了用户可觉察的性能对于一个支持缓存约束的基于网络的系统来讲，能够经过在中间层使用共享缓存所得到的好处来弥补这一缺点。正由于REST风格有这样的缺点，才会特地强调缓存的做用。
         7：按需代码，经过下载并执行applet形式或脚本形式的代码，REST容许对客户端的功能进行扩展，看似简单的一种风格设计，其实对B/S贡献最大的就是这个特性，如今ajax的底层其实就是按需代码机制。
        小结：基于网络的架构风格图形化地描述了REST约束的来源java

数据流风格（Data-flow Styles）程序员

   PF：管道和过滤器（Pipe and Filter，PF）
   UPF：统一管道和过滤器（Uniform Pipe andFilter，UPF）
复制风格（Replication Styles）
   RR：复制仓库（ReplicatedRepository，RR）--apache 多woker-利用多个进程提供相同的服务，来改善数据的可访问性（accessibility of data）和服务的可伸缩性（scalability of service）。CVS[www.cyclic.com]这样的远程版本控制系统
   $ 缓存（Cache，$）
分层风格（Hierarchical Styles）
客户-服务器（Client-Server，CS）(rpc,corba)
分层系统（Layered System，LS）和分层-客户-服务器（Layered-Client-Server，LCS）
客户-无状态-服务器（Client-Stateless-Server，CSS）
客户-缓存-无状态-服务器（Client-Cache-Stateless-Server，C$SS）
分层-客户-缓存-无状态-服务器（Layered-Client-Cache-Stateless-Server，LC$SS）
远程会话（Remote Session，RS）(FTP)
远程数据访问（Remote Data Access，RDA）(sql)
移动代码风格（Mobile Code Styles）
虚拟机（Virtual Machine，VM）
远程求值（Remote Evaluation，REV）
按需代码（Code on Demand，COD）
分层-按需代码-客户-缓存-无状态-服务器（Layered-Code-on-Demand-Client-Cache-Stateless-Server，LCODC$SS）
移动代理（Mobile Agent，MA
点对点风格（Peer-to-Peer Styles）
基于事件的集成（Event-based Integration，EBI）
C2
分布式对象（Distributed Objects，DO）
被代理的分布式对象（Brokered Distributed Objects，BDO）
以上就是REST推导过程，简单的说，REST要求
        1:客户端和服务器结构
        2:链接协议具备无状态性
        3:可以利用Cache机制增进性能
        4:层次化的系统
        5:统一接口规范分层交互
        6:随需代码 - Javascript （可选）
根据以上的描述，咱们其实发现HTTP是一种典型的REST风格，这也难怪，在1994年提出REST风格时，REST被称做“HTTP对象模型”，可是那个名称经常引发误解，令人们误觉得它是一个HTTP服务器的实现模型。这个名称“表述性状态转移”是有意唤起人们对于一个良好设计的Web应用如何运转的印象。反过来看HTTP就是REST的具体实现。在一个REST风格中，咱们可以感觉到的就是统一接口的数据，这些数据包括因此，当咱们开发一个web服务时，好比一个网站，因为使用了HTTP(HTTPS)协议，其实就是一种REST风格，可是在这个REST风格中咱们着重处理的是两点
       1：URI，即所谓的资源，网站的uri设计
       2：统一接口，即所谓的PUT,GET,POST,DELETE方法
虽然咱们的网站是REST的风格的，可是因为统一接口设计的很差，致使咱们网站在访问请求时，效率低下，以及可扩展性差。在深刻浅出REST中，做者总结了五条关键原
        1：为全部“事物”定义ID
        2：将全部事物连接在一块儿
        3：使用标准方法
        4：资源多重表述
        5：无状态通讯
其中前四条就是对统一接口中的数据元素，第一二条讲的就是uri，第三四条讲的是控制数据。第五条无状态通讯，这个须要特别说明下，无状态通讯是指服务器和客户端通讯是无状态的，假如咱们的系统中使用Session保存客户端状态，这种状况就是非无状态通讯，是一种unREST的方式。可是应用自己是有状态的，好比用户登陆先后，就是应用状态的变化。
       以上的描述，偏向理论东西最多，也不容易理解，咱们经过对比几组协议更好的理解REST
REST和HTTP的关系
       HTTP（HyperTextTransfer Protocol）超文本转移协议，中国的权威老是翻译成超文本传输协议，这是一种错误的翻译，HTTP一层应用协议，和传输没有一点关系。中国的砖家，自做多情翻译成传输，从这一刻起，开始修正吧，HTTP即为超文本转移协议。
       HTTP中第二个T和REST中的T都是一个含义：Transfer，转移的意思。前者是指超文本转移的，后者是说表述转移的，二者相同是有缘由的。前者是只具体数据的转移，后者是表述状态概念上转移。二者是一个抽象，一个实现的关系，相似于URI和URL的关系，这块在Roy Fielding的论文中也有体现，在1994年提出REST风格时，REST被称做“HTTP对象模型”，可是那个名称经常引发误解，令人们误觉得它是一个HTTP服务器的实现模型。这个名称“表述性状态转移”是有意唤起人们对于一个良好设计的Web应用如何运转的印象。因此，通俗的讲，HTTP就是在REST风格的一种具体实现。
         虽然，HTTP协议是REST的一个实现，可是并不意味着HTTP的全部特性都符合REST。
        1：HTTP没法区分权威的响应，没法区分请求来自目前服务器，仍是中间代理。
        2：COOKIE，使用cookie记录用户信息，明显违背了REST中的无状态特性，使数据传输不透明，同理对于Session也是违反REST。
        3：必须扩展。在现代Web架构中一个还没有匹配REST架构风格的自描述消息约束的方面，主要是由于在现有HTTP语法中实现一个支持必需扩展的框架的成本，超过了咱们可能从必需扩展中得到的任何明显的好处
        4：混合元数据。HTTP被设计用来跨越一个网络链接扩展通用的链接器接口。所以，它有意匹配这个接口的特性，包括将参数描述为控制数据、元数据、以及表述。然而，HTTP/1.x协议家族的两个最严重的局限是：它没有从语义上区分表述的元数据和消息的控制信息（都是做为头信息字段来传输）；并且不容许为了对消息进行完整性检查，而对元数据进行有效地分层。
        5：MIME语法，好比.html后缀，其实这并非HTTP协议所必须的。MIME语法的问题在于它假设传输机制是有损耗的，会故意将换行和内容长度等信息破坏掉。所以其语法有不少的冗余，而且对于任何并不是基于有损耗传输机制的系统来讲都是低效的，这使得它对于HTTP是不适合的。既然HTTP/1.1有能力支持不兼容协议的部署，保留MIME的语法对于HTTP的下一个主要的版本而言并非必需的，尽管如此，仍是有可能为表述的元数据继续使用不少标准化的协议元素。
        6：将响应匹配到请求，当须要描述哪个响应属于哪个请求的时候，HTTP消息并非自描述的。早期的HTTP基于每一个链接单个请求和响应，所以没有觉察到须要有将响应与相关的请求绑定在一块儿的消息控制数据。所以，请求的顺序决定了响应的顺序，这意味着HTTP依赖于传输机制的链接（transport connection）来决定这个匹配。
       总结起来讲，对于web开发者来讲，最长接触的就是cookie和mime语法，因此在架构良好的系统同，尽可能避免使用cookie，mime语法，也是一种REST方式。固然对于cookie要区分对待，并非使用cookie，就意外着违反REST风格，主要看cookie的应用场景，若是cookie用来记录客户端信息，而并不维护客户端状态，其实cookie仍是可使用。可是Session就是彻底反REST的，它违反了REST中的无状态性，咱们如今不少应用仍是喜欢使用Session记录用户登陆状态，其实这是一种unREST的方式。对于MIME，就HTTP协议来讲MIME并非必须的，若是有条件了能够不使用。
       固然，在HTTP协议制定过程当中，HTTP的不少特性也是在REST风格指导下定义的，好比，好比缓存控制cache-control，Etag；协议版本控制，HTTP-version。还有如今虚拟主机，就是由于Host字段，这也是REST风格对HTTP协议的做用。
REST和URI的关系
       HTTP是REST的一种实现，其实URI也是REST的一种实现，统一资源标识符（URI）既是Web架构的最简单的元素，也是最重要的元素。Web地址的规范也定义了咱们所称之为的“资源”的概念的范围和语义，这个概念自从早期的Web架构以来发生了变化。REST被用来为URI标准定义术语“资源”，也被用来定义经过它们的表述来操做资源的通用接口的所有语义。
       尽管URI的设计与REST的标识符的架构概念相匹配，单单依靠语法却不足以迫使命名权威按照资源模型来定义他们本身的URI。一种形式的滥用是在由一个超媒体响应形式的表述（a hypermedia response representation）所引用的全部的URI中包括标识当前用户的信息。这样内嵌的用户id可以被用来维护服务器端会话的状态，经过记录用户的动做来跟踪他们的行为，或者跨多个动做携带用户的首选项（例如Hyper-G网关[84]）。尽管如此，因为违反了REST的约束，这些系统会致使共享缓存变得效率低下，这下降了服务器的可伸缩性，而且在一个用户与其余用户共享那些引用时会致使不但愿的结果。另外一个与REST的资源接口的冲突发生在当软件试图将Web看做一个分布式文件系统的时候。这是URI和REST相反的两个方面，一开始你们看到第一条缘由时不是很了解，举个例子来讲，好比咱们有三个页面。
http://www.aizher.com/?uid=123
http://www.aizher.com/c2/?uid=123
http://www.aizher.com/item/123456.html?uid=123
       经过在url中传入uid记录跟踪用户的行为，以及维护和服务器端的回话状态，这是一种显著unREST的方式。再好比，在淘宝的web服务中，为了统计数据，在每一个url上加上spm，
http://www.tmall.com/yao?spm=1.1000386.221827.31.y2H5kz
        这种方式，是否违法REST？你们能够考虑下（答案是不违反的，具体缘由能够本身考虑）。
        至于第二条，其实更多的CDN（内容分发系统），CDN分发的是文件，因此能够很容易的作镜像，而对于web内容是作不到这样的，因此，CDN方式是URI一种特殊存在形式，不能推广到所有web内容。
REST和SOAP对比
        SOAP简单对象访问协议（SOAP，全写为Simple Object Access Protocol）是交换数据的一种协议规范，使用在计算机网络Web服务（web service）中，交换带结构信息。从这里能够看到SOAP是一种数据交换协议，而REST是一种架构风格，二者实际上是没有可比性的。可是为何老是把二者放在一块对比那？
        REST和SOAP以及XML-RPC实现方式不一样，可是目的是同样的，即提供web服务，做为一种总体来讲，因此你们喜欢把这三者进行对比。可是其本质上来讲，这三者不是一类东西，做为一篇介绍REST的文章，若是不说起SOAP的具体调用方式，你们是不会意识到REST的简单。
         SOAP是一种交换数据的协议规范，他自己不具有传输性，可是他可使用http协议，socket做为载体进行传输。一个典型的SOAP结构为

web

SOAP 消息必须用 XML 来编码
SOAP 消息必须使用 SOAP Envelope 命名空间
SOAP 消息必须使用 SOAP Encoding 命名空间
SOAP 消息不能包含 DTD 引用
SOAP 消息不能包含 XML 处理指令

         提到SOAP不得不提的是另外两个概念，WSDL,UDDI。WSDL（Web服务描述语言，Web Services Description Language）是为描述Web服务发布的XML格式。SOAP就是使用WSDL来描述web服务的。UDDI是统一描述、发现和集成（Universal Description, Discovery,and Integration）的缩写。它是一个基于XML的跨平台的描述规范，可使世界范围内的企业在互联网上发布本身所提供的服务。SOAP，WSDL，UDDI这三者是W3C中定义Web service的三个核心组件。
        SOAP：一个基于XML的可扩展消息信封格式，需同时绑定一个传输用协议。这个协议一般是HTTP或HTTPS，但也多是SMTP或XMPP。
        WSDL：一个XML格式文档，用以描述服务端口访问方式和使用协议的细节。一般用来辅助生成服务器和客户端代码及配置信息。
        UDDI：一个用来发布和搜索WEB服务的协议，应用程序可借由此协议在设计或运行时找到目标WEB服务。
三者能够相互独立，也能够相互融合使用，理想的应用场景是
        Web服务提供者：经过SOAP描述交互数据，使用WSDL描述服务器端口访问方式，在UDDI注册本身的Web服务，以方便调用者查找。
        Web服务的消费者：在UDDI上查找web 服务，调用WSDL得到服务接口的访问方式和接口细节，使用SOAP交互数据。以PHP为例（须要soap扩展），调用一个SOAPajax

[php] view plain copy

function soapCall($url, $functionName,$params) {
$c =new SoapClient($url, array('encoding'=>'GBK'));
$types = $c->__getTypes();
$paramArray = array();
for($i = 0; $i < count($params); ++$i) {
$p[$paramArray[$i]] = $params[$i];
}
$r =$c->$functionName($p);
foreach ($r as $key => $val) {
return $val;
}
}
$serviceUrl="http://xx.xxx.xxx.xxx:8047/MessageSenderWebService?wsdl";
$result =soapCall($serviceUrl,$serviceMethod,$ary);

综合上面所述，SOAP的缺点是

定义严格。必须符合SOAP的格式，参考规范要求。
须要有专门客户端解析soap协议，php须要soap扩展。
消息体大，大量信息用于描述Envelope，header。
服务器端，在web server的基础上，还须要单独部署服务，好比在jetty，tomcat须要部署AXIS。
服务器端代码可复用性差，这是相对于web来讲。
须要到注册中心UDDI发布，虽然是非必须条件，可是也同样会麻烦。
         SOAP方式的优势也很明显，格式规范标准，并在最重要的是有ws-*标准协议扩展保证数据交换的安全，规范。这点REST方式没有配套的协议，为了确保安全，基本上采用sign签名的方式，后面会详细讲解。
        小结：REST和SOAP本无对比性，放在一块的目的主要是说明SOAP如何使用，方便对比下面的REST方案。
REST和XML-RPC对比
         XML-RPC是一个远程过程调用（远端程序呼叫）（remote procedure call，RPC)的分布式计算协议，经过XML将调用函数封装，并使用HTTP协议做为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。如今直接使用XML-RPC的方式已经不多了。redis

REST与SOA对比
SOA面向服务的体系结构（Service-oriented architecture）是构造分布式计算的应用程序的方法。它将应用程序功能做为服务发送给最终用户或者其余服务。
SOA采用开放标准、与软件资源进行交互并采用表示的标准方式，SOA是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。这使得构建在各类这样的系统中的服务能够以一种统一和通用的方式进行交互。sql

参考SOA面向服务器的体系架构的定义，和REST的面向资源的体系架构（ROA）对比，发现二者有很多相同点，好比
        一、统一的服务契约接口与服务接口。
        二、松散的耦合。
        三、只要有权限均可以进行访问
REST与SOA的不一样点
       一、REST风格下的，只有一种协议，那就是HTTP。而SOA有多种协议，好比：TCP、HTTP等多种协议
       二、使用方式上的不一样。REST只要客户端可以模拟HTTP请求，经过标准的HTTP动做，均可以进行访问。
       三、REST寄宿时，虽然能够选择多种寄宿方式，但必须有应用服务器的支持。
        REST限定了http协议上的服务接口，松散耦合，而SOA没有这方面的限定，这一点的差别，在具体实现就千差万别。不管是REST风格，仍是ROA，或者SOAP，以及RMI等，其实都属于SOA的范畴。
        总结：REST和SOA的本质区别仍是资源与服务的区别，资源经过两部分定义：资源URL和资源所提供的全部操做上定义的输入/输出参数。服务并非某个编程结构或一组APIs，而是一个用于实现企业解决方案的架构（设计单元、实现以及维护）和部署构件，而且可由多种方式实现，资源和服务自己属于包含被包含的关系，因此REST与SOA也是包含于被包含的意思。
REST与RPC对比？
        REST和RPC自己也没有直接关系，REST是架构风格，而RPC是一个协议。远程过程调用（Remote Procedure Call，RPC）是一个计算机通讯协议。该协议容许运行于一台计算机的程序调用另外一台计算机的子程序，而程序员无需额外地为这个交互做用编程。若是涉及的软件采用面向对象编程，那么远程过程调用亦可称做远程调用或远程方法调用，例：Java RMI，CORBA, DCOM等等。
淘宝的HSF服务，其实就是一种RMI方法。
小结：
         经过REST与SOAP，SOA，XML-RPC，RPC，HTTP，URI的对比，咱们绘制以下关系图
apache

         REST风格是旨在解决服务器通讯的一种架构风格。REST，RPC，SOAP三者同为SOA的一种实现手段。其REST，RPC，SOAP自身又有不少与之关联的概念和技术，协议。但愿经过以上对比，先开REST的神秘面纱。
         REST提出概念后，其实并无像SOAP和RPC协议那样的火爆起来，其中一方面的缘由是REST并不像是SOAP和RPC协议那样，有个具体看的见的东西，他只是一种架构风格，属于高级抽象，在应用普及方面先天不足，外加上没有一个合适的爆发点。另外，在REST以前已经有了SOAP和RPC，因此在考虑到远程服务通讯时，你们首先想到的仍是这二者。REST热，是因为AJAX的火爆引发的。话说，2005年2月8日-google maps发布，让你们惊艳的是WEB能够作的这么帅，AJAX的概念随之火爆，而支持AJAX火爆的一个点就是REST，不管是SOAP仍是XML-RPC都没法很好的支持AJAX的请求，试想一下，ajax先调用wsdl，再调用服务接口，这个过程会让任何程序崩溃掉，在这里WSDL是没有任何用处，AJAX须要一种支持web服务，可是又不须要WSDL的方法，这时候天然而然的想到的REST，虽然AJAX中的X是XML的缩小，XML因为先天不足，在web服务中，逐渐被json取代。
         除了AJAX火爆外，SaaS(Software as a Service) 概念火爆，SasS，iaas，paas合在一块即云计算，云计算的兴起，尤为是内部云，更须要一种简单，方面的web服务通讯方式。而REST正好知足这方面的需求，部署简单，调用方便，客户端使用curl就能够。
         于此同时，2006年3月开始，亚马逊S3上线，真正的Restful API。2007年5月24日，facebook推出开放平台，SOAP，REST并存方式。2008年，淘宝开放平台，REST方式。人人，QQ，微博开放平台，REST方式。至此到之后作开放平台必须使用REST方式，而SOAP，XML-RPC方式在互联网行业几乎被遗忘，在讨论WEB服务时，动辄REST方式。
         REST的标签：云计算，开发平台，AJAX
REST之因此在云计算，开放平台，AJAX方面遍地开花，是因为REST的这些优势，正好符合云计算，开放平台，AJAX的应用场景。
1）轻量级的解决方案，没必要向SOAP那样要构建一个标准的SOAP XML。
2）可读性比较好:能够把URL的名字取得有实际意义。
3）不须要SDK支持：直接一个Http请求就能够，可是SOAP则可能须要使用到一些Web service的类库（例如Apache的Axis）

REST框架有哪些？
         REST是一种架构风格，而不是一种具体实现。而目前主流的WEB server又不能很好的支持REST，包括Apache。因此有机构，我的开发了很多REST框架，这些REST框架，说到底解决的就是HTTP的请求方法，对GET,POST,UPDATE,DELETE的处理，其余并没有新意，这些框架在实际应用中，效果并非很好，其中一条缘由是，REST框架又使REST风格变得复杂，通常状况下，不推荐使用。
         常见的REST框架有
         Ruby on Rails1.2之后的版本支持REST model。
        JBoss RESTEasy， JBoss的REST实现
        Restlet Tomcat的REST实现
        ZendFramework经过Zend_Rest组件来实现Rest功能，框架CakePHP，相似Rails风格。
        Apache Wink，java框架
        Project Jersey 是 Sun® 公司提供的、用于构建 RESTful Web 服务的。
微博，淘宝，微信开发平台，谁最REST
         1：微博API
                   访问连接：http://open.weibo.com/wiki/%E5%BE%AE%E5%8D%9AAPI
         微博的接口分为，微博接口，评论接口，帐号接口，好友分组接口等等分类，每种分类对应一组API接口，好比读取接口
         https://api.weibo.com/2/statuses/public_timeline.json（微博组）
         https://api.weibo.com/2/comments/show.json（评论组）
         https://api.weibo.com/2/users/show.json（用户组）
         其中URL中的2是版本，statuses,comments,users是每类的分组。微博的API，是通过赞成归还的，每种url表明一种资源，是一种REST方式，只不过2做为版原本使用有点2

2：淘宝的API
         访问连接：http://open.taobao.com/doc/index.htm?spm=0.0.0.0.uD2CE3
         淘宝API有
         用户API，提供了用户基本信息查询功能
        类目API，提供了标准类目，类目属性和类目属性值的查询功能
        商品API，提供了商品以及商品相关的sku，邮费增长，修改功能
        交易API，提供了订单下载，修改收货地址、修改交易备注等功能
        评价API，提供了评价的添加和查询功能
        物流API，提供了发货，物流单详情，区域地址和物流公司信息查询功能
        店铺API，提供了店铺查询，店铺自定义类目的查询和更新。
        分销API，提供了分销商信息和采购单信息的查询以及分销产品的添加和更新等功能
        旺旺API，提供了旺旺聊天记录，平均等待时间，客服评价统计，客服未回复人数和客服接待数等绩效考核功能
        淘客API，提供了淘宝客商品列表和淘宝客单品详情推广，店铺推广，类目和关键字推广以及淘客报表查询等功能.常见的淘客问题，请看该文档的“功能介绍”等26种API。在微博，QQ，淘宝这三种中开发接口数量最多的开发平台，开发总接口数，开放API总数多达200多个，维护管理这些API就须要不少技巧，这也是淘宝API比较奇葩的一种缘由。
http://gw.api.taobao.com/router/rest?sign=5029C3055D51555112B60B33000122D5&timestamp=2013-05-06+13%3A52%3A03&v=2.0&app_key=test&method=taobao.user.seller.get&format=xml&session=test&fields=nick
以上是淘宝API调用的主要方式，以上参数说明以下

名称	类型	是否必须	描述
method	string	Y	API接口名称
timestamp	string	Y	时间戳，格式为yyyy-mm-dd HH:mm:ss，例如：2013-05-06 13:52:03。淘宝API服务端容许客户端请求时间偏差为6分钟。
format	string	N	可选，指定响应格式。默认xml,目前支持格式为xml,json
app_key	string	Y	TOP分配给应用的AppKey ，建立应用时可得到
v	string	Y	API协议版本，可选值:2.0。
sign	string	Y	对 API 输入参数进行 md5 加密得到，详细参考以下 3、签名sign
sign_method	string	Y	参数的加密方法选择，可选值是：md5,hmac
session	string	N	TOP分配给用户的SessionKey(或 Access Token），经过登录受权获取，方法参考用户受权介绍。API 文档上 “API用户受权类型”标识为“须要”的，调用时均要传该参数

说淘宝开放接口是奇葩的缘由在于，http://gw.api.taobao.com/router/rest?在这个请求URL中，加了一个rest，难倒非要在URL中加上一个rest字样才算是REST么？
其次，淘客API有个router概念，全部的请求通过router转发处理，经过method控制router，全部的资源请求都是URL，而违法REST中的资源的要求。
再次，淘宝有些接口中有一个Session字段，用于传递用户受权状态，这是一种严重违REST的方式。
QQ的API。
        访问连接：http://wiki.open.qq.com/wiki/API%E5%88%97%E8%A1%A8
        QQ的API涉及用户信息类API,关系链类API，应用推广类API,营销类API，基础支持类API等，QQ的API最纠结，一种是经过接口得到数据方式
http://openapi.tencentyun.com/v3/user/get_info
         另一种是所谓的前端js接口，经过包括qq的跨域js文件，实现js的弹窗处理。：http://fusion.qq.com/fusion_loader?appid=[应用ID]&platform=[平台代码]
         QQ的开发平台，已经升级到v3版本，明显快于淘宝的（v1，淘宝已经放弃了对v的升级），微博的v2。QQ这方面的接口已经和微信的接口属于一个等级上，而且REST的定义方式，更优于微博，一方面是使用v3的方式，另一方面也去掉了微博上的.json后缀，这是值得确定的方式。提及来最纠结是，js接口调用方式，开发受权没有作好，采用js方式，作安全受权。
         综述，从REST角度来讲微博，淘宝，QQ这三种开发平台，微博作的2，可是最好，QQ最纠结，可是进步明显，淘宝最奇葩，违反REST约束。

REST常见问题问答
         Q：使用cookie算不算是REST?
         A：REST架构风格是有一条是服务器端是无状态的，cookie的方式，用于在记录客户端状态时，这时候是符合REST风格的。Cookie的问题在于，一旦种上Cookie，在全部的请求中都会带上Cookie信息，这种脱离请求上下文的Cookie，这会使得通讯的两端都产生混淆使用。是非REST方式的。REST应用，web 服务是无状态的，而应用是有状态的。
         Q：使用Session算不算REST？
         A：应用一旦使用Session，直接违反了REST中的web服务中无状态性，是非REST。
         Q：开发平台上的url常见的有v和format参数，为何要有这两个参数？是否符合REST规范？
         A：开发平台中v和format参数，是因为REST先天不足的缺点致使的，经过v控制版本，能够作系统升级时，向下兼容。format参数用于要求服务器返回特定表述，这两种能够在参数中约束，可是不是好方法，比较好的方法是，使用HTTP协议中的Accept，告诉客户端所须要的格式，和版本号，以下
”Accept: application/xml”
”Accept: application/xml verson=1.0”
         Q：开发平台上的sign旨在解决什么问题？
         A：REST在安全方面先天不足，不像SOAP同样，有一组WS-*协议，保证请求的安全性。因为REST没有这方面的标准，因此，只能从参数传递上作些技巧考虑，如sign加签名的方式，签名方式通常为参数组合字典排序，而后组合上用户申请的密钥，进行下md5，生成密钥，web服务上采用相同方式，进行验证，确保调用安全，对REST而已，有点小牛拉大车感受，像Facebook作了更多的尝试，好比Facebook的图API。
         Q：浏览器不支持http协议中的delete，update方法怎么办？
       A：浏览器默认操做都是GET方式的，支持post方式能够从form表单中设置，而想delete和update方式，可使用ajax进行请求处理。

综述：

         表征状态转移（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。目前在三种主流的Web服务实现方案中，由于REST模式的Web服务与复杂的SOAP和XML-RPC对比来说明显的更加简洁，愈来愈多的web服务开始采用REST风格设计和实现。
         REST 从资源的角度来观察整个网络，分布在各处的资源由URI肯定，而客户端的应用经过URI来获取资源的表征。得到这些表征导致这些应用程序转变了其状态。随着不断获取资源的表征，客户端应用不断地在转变着其状态，所谓表征状态转移（Representational State Transfer）须要注意的是，REST是设计风格而不是标准。REST一般基于使用HTTP，URI，和XML以及HTML这些现有的普遍流行的协议和标准。
    资源是由URI来指定。
    对资源的操做包括获取、建立、修改和删除资源，这些操做正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
    经过操做资源的表现形式来操做资源。
    资源的表现形式则是XML或者HTML，取决于读者是机器仍是人，是消费web服务的客户软件仍是web浏览器。固然也能够是任何其余的格式。

REST的要求
    客户端和服务器结构
    链接协议具备无状态性
    可以利用Cache机制增进性能
    层次化的系统
     随需代码 -Javascript （可选）

REST方式优势：
    1:能够利用缓存Cache来提升响应速度
    2:通信自己的无状态性可让不一样的服务器的处理一系列请求中的不一样请求，提升服务器的扩展性
    3:浏览器便可做为客户端，简化软件需求
    4:相对于其余叠加在HTTP协议之上的机制，REST的软件依赖性更小
    5:不须要额外的资源发现机制
    6:在软件技术演进中的长期的兼容性更好
     简单来说就是，轻量级的解决方案，没必要向SOAP那样要构建一个标准的SOAP XML，可读性比较好:能够把URL的名字取得有实际意义，不须要SDK支持：直接一个Http请求就能够，能够在AJAX中很好使用。
REST的缺点？
        REST的优势是轻量级解决方案，缺点就是在复杂的应用中，构造的URL会很长，影响人对URL的理解，不适合复杂应用。REST不能支持事务。在安全应用中，REST方式先天不足，须要后期策略补救。因为REST是一种架构风格，不是一个标准，加上每一个人理解差别，形成REST不能很好统一，规范困难。
         符合REST架构风格，必然有较好的软件扩展性，向下兼容性，可是彻底符合REST，对于如今的web服务来讲，也是一项沉重的负担，处理数据的增删改查，会比如今麻烦的多。不管黑猫白猫抓住老鼠就是好猫，关键是可以解决实际问题，TOP API解决了淘宝开发平台的问题，微博，QQ同时解决了本身开发平台问题，同时这些开发平台都提供了，本身的SDK包，方便调用这些接口，其实unREST is new REST。做为超过1W字的文章，最后结论是unREST is new REST，您确定不知足，你们须要了解的是实际开发中如何使咱们的工做更加REST化，
1：拒绝Session
2：有限使用Cookie
3：URL中避免使用动词，好比get，put，do之类的，尽可能使用名词，表示资源状态。
4：在同一url分别处理get，post请求。
补充：
         RESTful：RESTful Web 服务（也称为 RESTful Web API）是一个使用HTTP并遵循REST原则的Web服务，好比淘宝，腾讯，微博的开发平台就可说是提供RESTFul Web服务。
转帖注明：http://blog.csdn.net/ugg
参考资料：
《Architectural Styles and the Design of Network-basedSoftware Architectures？做者Roy Thomas Fielding，首次在这边论文中提到REST，REST之父，HTTP协议的主要做者之一。
《架构风格与基于网络的软件架构设计》是《Architectural Styles and the Design ofNetwork-based Software Architectures》译者为李锟、廖志刚、刘丹、杨光。其中李锟（ ajaxcn.org 网站站长）、廖志刚( 91yee 翻译社区负责人)、刘丹（ Matrix 技术社区负责人）、杨光（《重构与模式》的译者）以上几位都是互联网资深人士，翻译质量有保障。
白话REST-识别真假REST，http://download.csdn.net/detail/ugg/5576261
维基百科-REST： http://zh.wikipedia.org/zh-cn/REST ，以及相关资料
深刻浅出REST： http://www.infoq.com/cn/articles/rest-introduction/
对于REST中无状态(stateless)的一点认识：http://developer.51cto.com/art/200906/129424.htm
nobody-understands-rest-or-http ：blog.steveklabnik.com/2011/07/03/nobody-understands-rest-or-http.html
RESTFUL API 设计开发:http://wenku.baidu.com/view/277d37d484254b35eefd347d.html
REST介绍与REST在PHP中的应用: http://www.nowamagic.net/librarys/veda/detail/1247
理解RESTful架构： http://www.ruanyifeng.com/blog/2011/09/restful.html
设计 REST 风格的 MVC 框架： http://www.ibm.com/developerworks/cn/java/j-lo-restmvc/
REST架构： http://www.jdon.com/tags/1109/15 通俗易懂，对于容易混淆的概念讲解透彻
REST真相： http://www.jdon.com/36743
REST，Web 服务，REST-ful 服务： http://www.ibm.com/developerworks/cn/webservices/ws-RESTservices/
REST，Web 服务，REST-ful 服务： http://www.ibm.com/developerworks/cn/webservices/ws-restful/
基于 REST 的 Web 服务： http://www.ibm.com/developerworks/cn/webservices/ws-restful/
使用 WSDL 2.0 描述 REST Web 服务： http://www.ibm.com/developerworks/cn/webservices/ws-restwsdl/
最佳实践：更好的设计你的 REST API： http://www.ibm.com/developerworks/cn/web/1103_chenyan_restapi/
REST_百度百科： http://baike.baidu.com/view/1077487.htm
REST会是SOA的将来吗？ http://www.infoq.com/cn/articles/RESTSOAFuture/ 解答有关REST的十点疑惑 http://tech.sina.com.cn/s/s/2008-05-29/0936675195.shtml