一、什么样的应用才算是RESTful
REST 这个概念 2000 年就被提出来了，但2007 年才成为了一个热词，随后越来越多的服务都宣称自己是 RESTful 的，但是到底真么做才是真正的 (2007 年的时候 Ruby on Rails 也十分热门，所以我以为 Rails 风格的 CRUD API 就是 REST)
Richardson 的 REST 成熟度模型:
第 0 级服务：只使用一个 URI 作为一个服务端口，也只使用一个 HTTP 方法传输数据。大多数 WS-* 服务都是这个级别的，XML-RPC 和 POX 也是。这种做法相当于把 HTTP 这个应用层协议降级为传输层协议用。HTTP 头和有效载荷是完全隔离的，HTTP 头只用于保证传输，不涉及业务逻辑；有效载荷包含全部业务逻辑，因此 API 可以无视 HTTP 头中的任何信息。
第 1 级服务：使用多个 URI，不同的 URI 代表不同的调用入口，但只使用同一个 HTTP 方法传输数据。
第 2 级服务：使用多个 URI，不同的 URI 代表不同的资源，同时使用多个 HTTP 方法操作这些资源，例如使用 POST/GET/PUT/DELET 分别进行 CRUD 操作。这时候 HTTP 头和有效载荷都包含业务逻辑，例如 HTTP 方法对应 CRUD 操作，HTTP 状态码对应操作结果的状态。我们现在看到的大多数所谓 RESTful API 做到的也就是这个级别。
第 3 级服务：使用超媒体（hypermedia）作为应用状态引擎。
要解释这个概念先要解释什么是超媒体：
我们已经知道什么是多媒体（multimedia），以及什么是超文本（hypertext）。其中超文本特有的优势是拥有超链接（hyperlink）。如果我们把超链接引入到多媒体当中去，那就得到了超媒体，因此关键角色还是超链接。使用超媒体作为应用引擎状态，意思是应用引擎的状态变更由客户端访问不同的超媒体资源驱动。
举个例子来说，用户在论坛的帖子列表点击超链接进入某个帖子，这时候浏览器作为一个客户端就会去 GET 这个帖子的链接 URI，应用状态就切换为显示某个帖子了。接着用户输入回复提交表单，浏览器就会根据 form 上面的 action 属性 POST 内容给目标 URI，应用状态就再一次发生切换，完成了回复的存储。
使用超媒体与前面第 1 级、第 2 级的显著区别是，客户端不再和 URI 紧耦合。在第 1 级或者第 2 级的应用里面，客户端都需要知道资源使用的 URI 模版（如 /orders/{id}），然后要操作什么样的资源就生成什么样的 URI。超媒体客户端只知道入口 URI，之后的每一个 URI 都是通过超链接获得的。
还是用上述论坛例子来解释，假若这个论坛通过 Atom 协议支持非浏览器的客户端访问。客户端是不需要知道论坛帖子的 URI 模版的，因为客户端可以通过帖子列表的 Atom 获得帖子的超链接，然后在用户选择浏览帖子时获取对应 URI 的内容。获取回来的结果不会带有 form，但会带有 <link rel="reply" />，通过这个 link 客户端又知道了用户提交的回复应该发往哪个 URI。
扩展：REST 这篇论文作者 Roy Fielding 说「只有使用了超媒体的才能算是 REST」。简单来说，他认为第 3 级成熟度以外的都不算 REST。(我个人支持 Roy Fielding 对 REST 的严格定义，我也认为一个真正使用了超媒体实现应用状态引擎的服务非常了不起，但是在普通 CRUD API 能满足需求的情况下我觉得使用 CRUD API 也可以。)
二、REST架构概述
何为REST?
REST是英文Representational State Transfer的缩写，中文翻译为“表述性状态转移”，他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。Rest是设计基于命名资源而非消息的松耦合应用程序，例如：以 Uniform Resource Locators（URL）、Uniform Resource Identifiers（URI）和 Uniform Resource Names（URN）的形式 — 而非消息的松耦合 Web 应用程序的一种风格。
REST巧妙地借助已经验证过的成功的Web基础设施 — HTTP。Web上所有的东西（页面、图像等）本质上都是资源。而 REST 正是基于命名资源而非消息的，这就限制了底层技术的曝光，从而给应用程序设计中的松耦合提供了便利条件。REST 的魅力在于任何东西都可以成为资源，且表示方法也可以不同。
比如：http://www.nowamagic.net/librarys/veda/articles/888 (注意该 URL 是基于名词的) 该 URL 表示一个资源 — 文章为888的资源请求该资源就会调用 HTTP GET命令
http://www.nowamagic.net/librarys/veda/articles?id=888(该 URL 是基于动词的版本) 违反 REST 原则，因为它以articles的形式嵌套了一条消息。
REST优势
REST改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。
1. 无状态性
无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销，严重的降低了效率。
2. 缓存
为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。
B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST. REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。
3. 统一接口
REST架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。
4. 分层系统
分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。
5. 按需代码
REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。
REST规范接口
每个资源都有对应的URI，不同的HTTP Method对应的对资源不同的操作，GET（读取资源信息）、POST（添加资源）、PUT（更新资源信息）、DELETE（删除资源）。几乎所有的计算机语言都可以通过HTTP协议同REST服务器通信。
场景：
A:http://www.nowamagic.net/articles
B:http://www.nowamagic.net/articles/{id}
A网址：GET方法：显示全部用户信息；同时有个POST方法，用来添加用户； DELTE、PUT方法一般没提供。
B网址：GET方法：显示当前用户信息；PUT方法：更新用户信息；DELETE方法：删除该用户信息。
REST应用
目前国内外流行的Web 2.0应用API接口中，很多都支持REST架构风格。例如：新浪微博开放平台、人人网API、Google OpenID、Flickr、Twitter、eBay、Facebook、Last.fm、del.icio.us、Yahoo Search、Amazon S3、Amazon EC2、Digg、Microsoft Bing、FriendFeed、PayPal、Foursquare等。
三、REST风格中什么时候用HTTP、PUT、 HTTP、PUT
REST（Representational State Transfer）是网络服务接口的一种风格，并不是一个标准，就web service而言，REST要比SOAP（SOAP是标准，不是风格）轻量得多，容易得多。
因为REST只是风格，不是标准，所以有的方面容易有误解，比如说创建和更新某个URI代表的资源的时候，是用HTTP的PUT还是POST命令。REST常用的四种HTTP命令，GET、DELETE、PUT和POST，对于GET和DELETE，一个是获取资源，一个是删除资源，没什么异议，问题是PUT和POST，两者都有更改指定URI的语义，那么，究竟是用哪一个呢？
有的观点认为，应该用POST来创建一个资源，用PUT来更新一个资源；
有的观点认为，应该用PUT来创建一个资源，用POST来更新一个资源；
还有的观点认为可以用PUT和POST中任何一个来做创建或者更新一个资源。
这些观点都只看到了风格，争论起来也只是争论哪种风格更好，其实，用PUT还是POST，不是看这是创建还是更新资源的动作，这不是风格的问题，而是语义的问题。
REST是一种风格，但是还是依赖于HTTP协议，在HTTP中，PUT被定义为idempotent的方法，POST则不是，这是一个很重要的区别。
“Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”
上面是说：如果一个方法重复执行多次，产生的效果是一样的，那就是idempotent
举一个简单的例子：加入由一个博客系统提供一个Web API，模式是这样http://superblogging/blogs/post/{blog-name}，将{blog-name}替换为我们的blog名字，往这个URI发送一个HTTP PUT或者POST请求，HTTP的body部分就是博文，这是一个很简单的REST API例子。我们应该用PUT方法还是POST方法？取决于这个REST服务的行为是否是idempotent的，假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？如果产生了两个博客帖子，那就说明这个服务不是idempotent的，因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。
前一种情况，应该使用POST方法；后一种情况，应该使用PUT方法。
也许你觉得这个两个方法的差别没什么，用错了也不会有什么问题，但是你的服务一放到internet上，如果不遵从HTTP协议的规范，就可能给自己带来麻烦。
比如，没准Google Crawler也会访问你的服务，如果让一个不是indempotent的服务可以用indempotent的方法访问，那么你服务器的状态可能就会被Crawler修改，这是不应该发生的。
|
传输方式 |
对应操作 |
SQL语句 |
说明 |
|
GET |
R(read) |
SELECT |
获取资源 |
|
POST |
C(create) |
CREATE |
创建资源 |
|
PUT |
U(update) |
UPDATE |
更新资源，客户端需要提供新建资源 的所有属性 |
|
DELETE |
D(delete) |
DELETE |
删除资源 |
|
path |
U(update) |
UPDATE |
更新资源的部分属性（很少用 |
|
HEAD |
只获取某个资源的头部信息 |