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