何为 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