REST 总览

REST ，英文全称是 Representational State Transfer ，翻译成中文是“表述性状态转移”。REST 这个术语是由 Roy Fielding 在他的博士论文 《 Architectural Styles and the Design of Network-based Software Architectures 》中提出的。REST是基于一些现有的流传较广的协议和标准，例如 HTTP， URI，以及XML等，由因为 REST，HTTP 协议有了更加正确的使用。我们可以将REST理解为设计模式的一种，它不是标准，只是一种用来开发Web 应用的架构风格。 

REST模式与基于 SOAP 和 WSDL 的 Web 服务相比的优势在于REST提供的实现方案更为简洁。REST 提供的是松耦合的 Web 服务，适合为客户创建在互联网传播的轻量级的 Web 服务的API。REST 应用的请求和响应是以“资源表述的转移（the transfer of representations of resources）”为中心进行的。我们称的资源包括数据和各种功能，如果要访问资源，只需要使用统一的资源标识符（URI）即可。我们常见的网页中的链接就是典型的 URI。该资源是通过文档进行描述的，由一组简单的、有明确定义的操作执行。

例如，一个 REST 资源可能是一座城市当前的天气情况。可能通过一个XML文档、图像文件或者HTML页面来对该资源进行表述。我们的客户端能够检索特定的表述，通过更新其数据修改的资源，或者完全删除该资源。

现在，REST 风格越来越受欢迎，而且很多 Web 服务也开始采用它来设计与实现，目前我们所知道的比较著名的 REST 服务包括了：Google AJAX 搜索 API、Amazon Simple Storage Service (Amazon S3) 等。

为了能够让 RESTful 应用是轻量的，简单的并且更快开发，基于 REST 的 Web 服务需要遵循以下一些基本的设计原则：

• 通过 URI 来标识资源:系统中的每一个对象或是资源都可以通过一个唯一的 URI 来进行寻址，URI 的结构应该简单、可预测且易于理解，比如定义目录结构式的 URI。
• 统一接口：以遵循 RFC-2616 所定义的协议的方式显式地使用 HTTP 方法，建立创建、检索、更新和删除（CRUD：Create, Retrieve, Update and Delete）操作与 HTTP 方法之间的一对一映射：
  • 若要在服务器上创建资源，应该使用 POST 方法；
  • 若要检索某个资源，应该使用 GET 方法；
  • 若要更新或者添加资源，应该使用 PUT 方法；
  • 若要删除某个资源，应该使用 DELETE 方法。
• 资源多重表述:URI 所访问的每个资源都可以使用不同的形式加以表示（比如 XML 或者 JSON），具体的表现形式取决于访问资源的客户端，客户端与服务提供者使用一种内容协商的机制（请求头与 MIME 类型）来选择合适的数据格式，最小化彼此之间的数据耦合。在 REST 的世界中，资源即状态，而互联网就是一个巨大的状态机，每个网页是其一个状态；URI 是状态的表述；REST 风格的应用则是从一个状态迁移到下一个状态的状态转移过程。早期互联网只有静态页面的时候，通过超链接在静态网页间浏览跳转的 page->link->page->link… 模式就是一种典型的状态转移过程。也就是说早期的互联网就是天然的 REST
• 无状态:对服务器端的请求应该是无状态的，完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。通过超链接实现有状态交互，即请求消息是自包含的（每次交互都包含完整的信息），有多种技术实现了不同请求间状态信息的传输，例如 URI 重新，cookies 和隐藏表单字段等，状态可以嵌入到应答消息里，这样一来状态在接下来的交互中仍然有效。REST 风格应用可以实现交互，但它却天然地具有服务器无状态的特征。在状态迁移的过程中，服务器不需要记录任何 Session，所有的状态都通过 URI 的形式记录在了客户端。更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；这里所指无状态服务器均指无会话状态服务器。

Java REST

针对 REST 在 Java 中的规范，主要是 JAX-RS（Java API for RESTful Web Services），该规范使得 Java 程序员可以使用一套固定的接口来开发 REST 应用，避免了依赖于第三方框架。同时，JAX-RS 使用 POJO 编程模型和基于标注的配置，并集成了 JAXB，从而可以有效缩短 REST 应用的开发周期。Java EE 6 引入了对 JSR-311 的支持，Java EE 7 支持JSR-339 规范。

JAX-RS 定义的 API 位于 javax.ws.rs 包中。

伴随着 JSR 311 规范的发布，Sun 同步发布该规范的参考实现 Jersey。JAX-RS 的具体实现第三方还包括 Apache 的 CXF 以及 JBoss 的 RESTEasy 等。未实现该规范的其他 REST 框架还包括 SpringMVC 等。

截至目前， JAX-RS 最新的版本是 2.0 （JSR-339）

Why Jersey

在 Java 中，既然 规范的制定者和实现者都是 Sun 公司（现在是 Oracle）,那么 Jersey 毫无疑问就是事实上的标准，对于 Java REST 的初学者来说尽量要跟着标准走。当然，所有规范的实现，在用法上基本上没有差别，只是相对来说 Jersey 的实现更全面一些。

本书所有的例子都是基于 Jersey 的，有关 Jersey 的参考，可详见《Jersey 2.x 用户指南》。