大家对REST的认识？
谈到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约束的来源
数据流风格（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结构为
- 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扩展），调用一个SOAP
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的方式已经很少了。
REST与SOA对比
SOA面向服务的体系结构（Service-oriented architecture）是构造分布式计算的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。
SOA采用开放标准、与软件资源进行交互并采用表示的标准方式，SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
参考SOA面向服务器的体系架构的定义，和REST的面向资源的体系架构（ROA）对比，发现两者有不少相同点，比如
1、统一的服务契约接口与服务接口。
2、松散的耦合。
3、只要有权限都可以进行访问
REST与SOA的不同点
1、REST风格下的，只有一种协议，那就是HTTP。而SOA有多种协议，比如：TCP、HTTP等多种协议
2、使用方式上的不同。REST只要客户端能够模拟HTTP请求，通过标准的HTTP动作，都可以进行访问。
3、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的对比，我们绘制如下关系图
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×tamp=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