1.1　解读REST

REST（Representational State Transfer，表述性状态转移），源于REST之父Roy Thomas Fielding博士在2000年就读加州大学欧文分校期间发表的一篇学术论文——《Architectural Styles and the Design of Network-based Software Architectures》。论文中提出了REST的6个特点，分别是：客户端-服务器的、无状态的、可缓存的、统一接口、分层系统和按需编码。在此不敢“班门弄斧”，希望读者阅读一下这部开山之作，以此理解REST产生的原因和特点。

REST具有跨平台、跨语言的优势。从其诞生开始，广泛地得到了诸多语言的快速支持，比较著名的是ROR（Ruby on Rails）。ROR非常强调规约大于配置的理念，这一理念被诸多框架和工具支持——包括以Python领域的Django、Groovy领域的Grails为代表的框架，以及Maven、Gradle为代表的构建工具等，但REST本身只规定了面向资源，并没有包含如何定义和约束一个资源的标准。因此要提示读者，很多实现了REST的框架和工具所具备的特质，其全部特征未必都是REST定义的，包括本书要讲的JAX-RS标准的定义和Jersey等JAX-RS的实现。

REST在众多平台和语言上的支持，不仅包括上述列举的传统编程语言、脚本语言，还包括Node.js这样新兴的服务器端脚本语言。REST的无状态，代理友好性等优势，使对其支持的实现更加方便和简洁。

1.1.1　一种架构风格

REST是一种架构风格。在REST架构风格中，对象被抽象为一种资源（resource），资源的命名使用概念清晰的名词来定义。表述性状态是对资源数据在某个瞬间状态的快照，资源的某个瞬时状态被定义为一种表述（representation），这种描述性的状态包括资源数据的内容、表述格式（比如XML、JSON、Atom）等信息，一种资源可以对应多种表述。REST的资源是可寻址的，通过HTTP协议（RFC 2616）定义的通用动词方法（比如GET、PUT、DELETE、POST），并使用URI协议（RFC 3305）来唯一标识某个资源公布出来的接口。请求一个资源的过程可以理解为，访问一个具有指定性和描述性的URI，经由HTTP，将资源的表述从服务器转移到客户端，或者相反方向。

REST不是一种技术（technology），也不是一个标准（standard）或协议（protocol），它使用既有标准：HTTP+URI+XML，来实现其要求的架构风格。因此，与之对应的不是SOAP，而是像RPC这样的架构风格。

1.1.2　基本实现形式

HTTP+URI+XML是REST的基本实现形式，但不是唯一的实现形式。REST从推出时就使用已有的HTTP协议、URI协议来描述，而对如何使用一种编程语言来实现，并没有进行任何描述和规定，甚至对于REST应该包含哪些传输类型或者数据格式也没有描述，但通常的实现至少包含XML格式。具体而言，HTTP协议和URI用于统一接口和定位资源，文本、二进制流、XML和JSON等格式用来作为资源的表述。正如采用已有技术XMLHttpRequest+JavaScript+XML（XML后来几乎被JSON替代）实现AJAX一样，使用HTTP+URI+XML实现REST的好处是让开发者持有这些已知的技术来开发REST，入门门槛较低，关注点更容易放到REST的核心概念和业务逻辑上。

这里要提示读者的是，以HTTP+URI+XML实现的应用并不一定是REST式的，但对于AJAX，这个逆命题（以XMLHttpRequest+JavaScript+XML实现的应用一定是AJAX应用）是成立的。因为AJAX是一种“技术流派”，而REST是一种架构风格。学习和使用REST的关键是掌握这种思想，而不是具体的实现形式。