REST学习笔记

参考:

http://baike.baidu.com/view/1077487.htm

http://www.infoq.com/cn/articles/rest-introduction/

REST(Representational State Transfer表述性状态转移), 是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。REST 定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。 如果考虑使用它的 Web 服务的数量，REST 近年来已经成为最主要的 Web 服务设计模型。 事实上，REST 对 Web 的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。REST 的主要框架已经开始出现，但仍然在开发中。它已经被广泛接纳到各个平台中，例如通过 JSR-311 成为了 Java™ 6 不可或缺的部分。

REST正在成为一个主流的Web API设计模式（Design Model）。

REST原则

REST定义了Web的使用标准（这和大多数人的实际使用方式有很大不同），例如HTTP和URI。如果你在设计应用程序时能坚持REST原则，那就预示着你将会得到一个使用了优质Web架构（这将让你受益）的系统。

为所有“事物”定义ID

REST中的资源所指的不是数据，而是数据和表现形式的组合。
资源标识符就是 URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。对资源使用一致的命名规则（naming scheme）最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义，在全球范围中几乎完美运行，并且能被绝大多数人所理解的规则。

通常，值得被URI标识的事物—资源—要比数据库记录抽象的多。标识所有值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈判、一份报价请求——这都是应该被标识的事物的示例。同样，这也会导致创建比非RESTful设计更多的持久化实体。

尽量创建便于阅读的URI——这是个有用的观点，尽管不是RESTful设计所必须的——应该能十分容易地推测出URI的含义。除了对单一资源创建标识，也可以对资源的集合创建标识。因为这些集合自身也是事物（资源），也应该被标识，比如所有在2007年11月份提交的定单。

将所有事物链接在一起

使用URI表示链接的优雅之处在于，链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通。

超媒体原则还有一个更重要的方面——应用“状态”。简而言之，实际上服务器端（如果你愿意，也可以叫服务提供者）为客户端（服务消费者）提供一组链接，使客户端能通过链接将应用从一个状态改变为另一个状态。

对此原则总结如下：任何可能的情况下，使用链接指引可以被标识的事物（资源）。

使用标准方法

在前两个原则的讨论中暗含着一个假设：接收URI的应用程序可以通过URI明确地做一些有意义的事情。它知道如何去处理URI的原因在于所有的资源都支持同样的接口，一套同样的方法（只要你乐意，也可以称为操作）集合。在HTTP中这被叫做动词（verb），除了两个大家熟知的（GET和POST）之外，标准方法集合中还包含PUT、DELETE、HEAD和OPTIONS。这些方法的含义连同行为许诺都一起定义在HTTP规范之中。

PUT、GET、DELETE方法都具有幂等性。POST方法，通常表示“创建一个新资源”，也能被用于调用任意过程，因而它既不安全也不具有幂等性。

为什么使用标准方法如此重要？从根本上说，它使你的应用成为Web的一部分——应用程序为Web变成Internet上最成功的应用所做的贡献，与它添加到Web中的资源数量成比例。采用RESTful方式，一个应用可能会向Web中添加数以百万计的客户URI。统一接口也使得所有理解HTTP应用协议的组件能与你的应用交互。

总结如下：为使客户端程序能与你的资源相互协作，资源应该正确地实现默认的应用协议（HTTP），也就是使用标准的GET、PUT、POST和DELETE方法。

资源多重表述

总结：针对不同的需求提供资源多重表述。

无状态通信

需要着重强调的是，虽然REST包含无状态性（statelessness）的观念，但这并不是说暴露功能的应用不能有状态——事实上，在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间（footprint）。

除此以外，其它方面可能显得更为重要：无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。

REST除了给我们带来了一个崭新的架构以外，还有一个重要的贡献是在开发系统过程中的一种新的思维方式：通过url来设计系统的结构。根据REST，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果url是设计良好的，那么系统的结构就也应该是设计良好的。

如果每个用户需求都可以抽象为资源，那么就可以完全使用REST。由此看来，使用REST的关键是如何抽象资源，抽象得越精确，对REST的应用就越好。

Constraints

参考：http://en.wikipedia.org/wiki/Representational_state_transfer

The REST architectural style describes the following six constraints applied to the architecture, while leaving the implementation of the individual components free to design:

Client–server (客户端-服务器模式)

A uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that theportability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and morescalable. Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.

Stateless （无状态的）

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.

Cacheable （可缓存的）

As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.

Layered system （分层的系统）

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies.

Code on demand (optional) （可按需编写的代码）

Servers can temporarily extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such asJava applets and client-side scripts such asJavaScript.

Uniform interface （统一的接口）

The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below.

The only optional constraint of REST architecture is "code on demand". One can characterise applications conforming to the REST constraints described in this section as "RESTful".^[8] If a service violates any of the required constraints, it cannot be considered RESTful.

Complying with these constraints, and thus conforming to the REST architectural-style, enables any kind of distributed hypermedia system to have desirableemergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability.