RESTful概念理解
基础
REST 定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。
如果考虑使用它的 Web 服务的数量，REST 近年来已经成为最主要的 Web 服务设计模型。 事实上，REST 对 Web 的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。
REST 这个概念于 2000 年由 Roy Fielding 在就读加州大学欧文分校期间在学术论文“Architectural Styles and the Design of Network-based Software Architectures”（请参见参考资料以获取此论文的链接）首次提出，他的论文中对使用 Web 服务作为分布式计算平台的一系列软件体系结构原则进行了分析，而其中提出的 REST 概念并没有获得现在这么多关注。 多年以后的今天，REST 的主要框架已经开始出现，但仍然在开发中，因为它已经被广泛接纳到各个平台中，例如通过 JSR-311 成为了 Java™ 6 不可或缺的部分。
本文认为，对于今天正在吸引如此多注意力的最纯粹形式的 REST Web 服务，其具体实现应该遵循四个基本设计原则：
- 显式地使用 HTTP 方法（GET、
PUT、POST、DELETE）。 - 无状态。
- 公开目录结构式的 URI。
- 传输 XML、JavaScript Object Notation (JSON)，或同时传输这两者。
参考：http://www.ibm.com/developerworks/cn/webservices/ws-restful/
RESTful 服务
REST 描述了可用来实现联网系统的一种设计模型。REST 既不是一种技术也不是一种标准；它是用来通过 Web 公开资源的一种架构风格。RESTful 架构遵从以下几个原则：
请求是客户-服务器 式的，并很自然地使用一种基于拉的交互风格。对组件的使用会从服务器中拉出状态的表示。
请求是无状态的。每个从客户端到服务器端的请求都必须包含理解此请求所需的全部信息，而且不能利用服务器上所存储的上下文。
REST 并不一定就意味着在中间层没有任何状态；为实现对某资源的请求的这个状态并不依赖于该状态。
客户机和服务器都遵从统一的接口。所有的资源都可通过 Web 扩展的 SOA 世界中的普通接口进行访问 —— HTTP 及 HTTP 方法：GET、POST、PUT 和 DELETE。
客户机与命名的资源进行交互。此系统由使用 URL（比如 HTTP URL）命名的资源组成。
REST 是表示 Web 中的服务的关键技术。REST 在公开基于数据的服务方面效果最好，理解这一点非常重要。这些数据服务进而可以混合和匹配以便构建新的应用程序（通常称为 mashup）。如下的示例展示了客户机是如何对待 RESTful 服务的。
用 http://<host>/customer：
GET：返回客户列表
POST：创建客户记录
用 http://<host>/customer/roland：
GET：返回 Roland 客户记录
PUT：更新 Roland 记录
DELETE：删除 Roland 记录
在本例中，所公开的资源是 Customer。此 Customer 用 URI /customer 表示。特定的客户则通过在 Customer 之后追加标识符加以表示，例如 /customer/ims。HTTP 报头方法定义了访问此资源的意图。
参考：https://www.ibm.com/developerworks/cn/web/i-zero1/
何为 REST?
RESTful
REST (Representation State Transfer) ful 就是 fulfil（履行, 满足, 完成, 落实, 兑现, 实践）
REST 是设计基于命名资源 — 例如，以 Uniform Resource Locators（URL）、Uniform Resource Identifiers（URI）和 Uniform Resource Names（URN）的形式 — 而非消息的松耦合 Web 应用程序的一种风格。REST 巧妙地借助已经验证过的成功的 Web 基础设施 — HTTP。换句话说，REST 利用了 HTTP 协议的某些方面，例如 GET 和 POST 请求。这些请求可以很好地映射到标准业务应用程序需求，诸如创建、读取、更新和删除（CRUD），如表 1 所示：
表 1. CRUD/HTTP 映射
| 应用程序任务 | HTTP 命令 |
|---|---|
| 创建 | POST |
| 读取 | GET |
| 更新 | PUT |
| 删除 | DELETE |
请求就像是动词，而资源就像是名词，把两者相关联就形成了对行为的逻辑表达 — 例如， GET 这个文件，DELETE 那条记录。
真正的 REST 之父 Roy Fielding 在他的博士毕业论文中陈述到：REST “强调组件交互的可伸缩性、界面的普遍性、独立部署组件以及使用中间组件来减少交互延迟，增强安全性并封装遗留系统”（参见 参考资料）。构建 RESTful 系统并不难，且这样的系统具有高度的可伸缩性，同时与底层数据松散耦合；这样的系统还可以很好地利用缓存。
Web 上所有的东西（页面、图像等）本质上都是资源。而 REST 正是基于命名资源而非消息的，这就限制了底层技术的曝光，从而给应用程序设计中的松耦合提供了便利条件。例如，下面的 URL 在不暗示任何底层技术的情况下，公开了资源：http://thediscoblog.com/2008/03/20/unambiguously-analyzing-metrics/。
该 URL 表示一个资源 — 一篇名为 “Unambiguously analyzing metrics” 的文章。请求该资源就会调用 HTTP GET 命令。注意该 URL 是基于名词的。基于动词的版本（大概类似 http://thediscoblog.com/2008/03/20/getArticle?name=unambiguously-analyzing-metrics）会违反 REST 原则，因为它以 getArticle 的形式嵌套了一条消息。您也可以设想通过 HTTP 的 POST 命令来发布一个新资源，（比如说，一篇诸如 http://thediscoblog.com/2008/03/22/rest-is-good-for-you/ 的文章）。你还可以设想用关联的、基于动词的 API — 如 createArticle?name=rest-is-good-for-you and deleteArticle?name=rest-is-good-for-you — 这样的调用来拦截 HTTP GET 命令，并最大限度地忽略已有的（并且是成功的）HTTP 基础设施。换句话说，它们不是 RESTful 风格。
REST 的魅力在于任何东西都可以成为资源，且表示方法也可以不同。在前面的例子中，资源为一个 HTML 文件，因此，其响应可能是 HTML 格式的。但是资源也可以是一个 XML 文档、序列化的对象或者 JSON 表示。其实，这些都无关紧要。重要的是资源被命名了，并且与它通信不会影响其状态。不影响状态是很重要的，因为无状态的交互有利于可伸缩性。
它的价值在那里？
引用达芬奇的一句名言 “简洁就是终极复杂”。万维网的实现非常简单，并且无可置否地获得了成功。REST 正是利用了 Web 的简单性，并因此造就了高度可伸缩的、松散耦合的系统，而且事实证明，这样的系统很容易构建。
正如您所看到的，构建 RESTful 应用程序最难的部分在于确定要公开的资源。解决了这个问题之后，再使用开源 Restlet 框架构建 RESTful Web 服务就是小菜一碟了。
http://www.ibm.com/developerworks/cn/education/java/j-rest/j-rest.html
