下面是维基百科的原文翻译：
Representational state transfer

前言

在计算机中，representational state transfer(REST)是一种应用于web开发的架构风格，使用这种风格设计的系统意在追求高性能，可靠性以及扩展能力(增长且容易支持更多的用户)。为了达到这些目标，开发者使用可重用组件，它们能在整个系统运行时可以被管理并且更新，而不会对系统造成影响。
从技术上来说，REST由分布式超媒体系统中一系列协作的组件，连接体以及数据元素组成，这个系统关注于组件角色以及数据元素而不是实现细节之间的一组具体交互。它的目的是促进性能，可伸缩性，可修改性，可见性，可移植性以及可靠性。REST是World Wide Web的一种软件架构风格。
术语representational state transfer在2000年被Roy Fielding在他的博士论文中出现，并且被定义。REST已经被用于描述理想的web架构，辨别存在的问题，比较可替代的方案并且确保协议扩展不会违反那些使web成功的核心约束。Fielding使用REST定义HTTP1.1和统一资源定位符(Uniform Resource Identifiers)。
名字representational state transfer意在勾勒一幅一个设计良好的web应用怎样运作的图像：一个由web页面组成的网络(一个虚拟状态机)，用户通过点击超链接(状态转移)来继续访问到下一个页面(代表下一个应用的状态)，这个页面被传输给用户并且被渲染。
系统遵循REST限制就能被称之为RESTFUL。典型的RESTFUL系统，但并不是全部，在HTTP协议之上使用相同的HTTP动词(GET,POST,PUT,DELETE,etc)进行信息交换，web浏览器运用这些动词来获取网页并且向远程服务器发送数据。REST系统作为一个用URI来标识的web资源来与外部系统交互，比如/people/tom，能够使用标准动词如GET /people/tom来操作。

内容

1. 历史
2. 架构的属性
3. 架构的限制

• client-server
• 无状态
• 可缓存
• 分层的系统
• 按需编码
• 统一接口

4. 应用于web服务

• URL与HTTP方法之间的关系

历史

REST于2000年被Roy thomas Fielding在他的博士论文Architectural Style and the Design of Network-based Software Architectures中定义的。Fielding基于1996已经存在的HTTP1.0设计，于1996·1999间与HTTP1.1并行开发了REST架构的风格。
回顾一下在REST发展过程中Roy Fielding说过：

• 在整个HTTP标准化过程中，让我去辨证Web的设计选择。对于一个迅速成为整个工业中心的主题，接纳来自任何人建议的过程是一个极其困难的事。我已经评论超过500的开发者，他们中的大多数都是有数十年经验的卓越工程师，我不得不从Web交互最抽象的标记深入到HTTP语法细节来详细解释其中一切。这个过程把我的模型打磨成一些列核心原则，特性以及约束。

架构特性

被REST架构风格约束影响的架构特性如下：

• 性能 - 在用户能感知到的性能和网络效率中，组件交互能成为优势因素。
• 可伸缩性在组件之中，能支持大量组件和交互。Roy Fielding--HTTP规范的主要作者，描述REST对可伸缩性的影响如下：
  • REST的client-server分离简化了组件实现，降低了连接器语义的复杂性，提升了性能调整的效率，并且增加了纯服务端的可伸缩性。分层系统的限制允许中介-代理，网关和防火墙-在交流中的任意点被引入，而无需改变组件之间的接口，因此允许它们有助于通信交换或者通过大规模、可共享的缓存来提高性能。REST通过约束消息为自描述来使得中间处理成为可能：交互在请求之间是无状态的，标准化的方法和媒体类型被用来标识语义和交换信息，并且显示指明响应是否缓存。
• 一个统一接口的简单性
• 组件的可修改性满足了变化需求（即使在应用运行期间）
• 通过服务agent可知道组件之间交流的可见性
• 通过移动带数据的程序代码获得组件的可移植性
• 可靠性是从系统层面，在组件，连接器或者数据出现失败时的一种抵抗失败的特性。

架构限制

REST的架构特性通过把具体交互约束应用于组件、连接器和数据的时候才能很好地被理解。只要遵循本节描述的REST约束，你的系统就能称之为RESTFUL。遵守这些约束，并且遵守REST架构风格，使得任意一种超媒体系统具备有吸引力的非功能特性，比如性能，可伸缩性，简单性，可修改性，可见性，可移植性以及可靠性。
标准的REST限制是：

• Client-server
  一个统一接口把客户端从服务端分离出来。分离关注点意味着客户端不必关心服务端的数据存储，它仅属于服务器内部功能，所以客户端的可移植性代码被提升了。服务端并不关心用户接口，或者用户状态，所以服务端能更加简单和可伸缩。服务端和客户端也能被独立替换或者开发，前提是只要它们之间的接口没有被改变。
• 无状态
  client-server数据交换能通过服务器上，在每个请求之间不存储客户端上下文来进一步进行限制。来自任意客户端的每个请求都包含所有服务这个请求的必要信息，并且session状态被保存在客户端。session状态能够被服务器转移到其它服务，比如数据库，它在维护一个有生命周期的持久化状态并且允许鉴权。当它准备好转换到一个新的状态时客户端就开始发送请求。虽然一个或者更多请求正在进行，客户端被认为在转变。每个应用状态的表现层包含一个可以用来转向下一个状态的链接。
• 可缓存
  在World Wide Web上，客户端和中间媒介能够缓存响应。响应必须显示或者隐式地定义它们自己是否可以被缓存，否则将使客户端在之后的请求中，重用响应中过期或者不合适的数据。管理良好的缓存部分或者全部消除了一些client-server交互，进一步提高了可伸缩性和性能。
• 分层的系统
  一个客户端通常不能区分它是否直接连接到终端服务器或者中介服务器。中介服务器可以通过启动负载均衡和提供共享缓存来增加系统的可伸缩性。它们同时也加强了安全策略。
• 按需编码
  服务端通过可执行代码，能够暂时扩展或者定制化一个客户端的功能。这个例子中可以包含可执行的组件，比如Java applets以及客户端脚本，如JavaScript。
• 统一接口
  统一接口限制是任何REST服务设计的基础。统一接口简化且解耦了架构，使得每一部分都能独立运行。对统一接口的四个限制如下：
  • 资源的定位
    比如在基于web的REST系统中通过URIs来确认请求中的独立资源。资源本身与那些返回给客户端的表现层是概念上相分离的。
    比如服务端可以从它的数据库发送数据，如HTML、XML、JSON，它们都不是服务器的内部表现形式。
  • 通过表现层操作资源
    当一个客户端保存了一个资源的表现层，包括任何附加的元数据，它就有足够的信息来修改和删除资源。
  • 自描述信息
    每个消息包含足够的信息来描述如何处理这个信息。比如，调用哪个解析器可以通过一个互联网媒体类型（以前称之为MIME类型）来具体化。
  • 超媒体作为应用状态的引擎
    客户端仅通过服务端动态指定的动作来做状态转换（比如超文本中的超链接）。
    一个应用除了简单固定的入口点，客户端并不会认为对于超出之前从服务器收到的描述于表现层的任意特殊动作对任意资源都可用。在两个资源之间，对于表示层链接并没有统一的接收格式。对于具体的REST超媒体链接，RFC 5988和JSON超媒体API语言是两种流行的格式。

应用于web服务

遵循REST架构限制的Web服务APIs被称之为RESTful APIs。基于HTTP的RESTful APIs从下列方面被定义：

• 基本URL， 比如http://example.com/resources/
• 定义状态转换数据元素的互联网媒体类型（比如，Atom，microformats，application/vnd.collection+json等等）。当前表示层告诉客户端如何组合所有转换到下一个应用状态。这既能像URL一样简单，也能像java applet一样复杂。
• 标准的HTTP 方法（比如，OPTIONS， GET， PUT以及DELETE）

URL和HTTP方法之间的关系
下表展示了一个HTTP方法在RESTful API中的典型应用：

PUT和DELETE方法被指定为幂等，即无论它们重复执行多少次，结果都一样。GET方法是一个安全方法，即调用它并不会产生副作用。换句话说，获取或访问一个记录并不会改变它。PUT/DELETE和GET的区别与the notion of Command-Query Separation (CQS)十分相似。比如A查询操作（如GET）期望在被查询的数据中没有副作用。命令(PUT/DELETE)对这个数据没有疑问，但是它会计算应用于数据的变化（比如更新或者插入将会使用数据库关键字）。
不像基于SOAP的web服务，对于RESTful web服务APIs没有一个官方标准。这是因为REST是一种架构风格，而SOAP是一种协议。即使REST不是一个标准，大多数RESTful实现都利用了标准，比如HTTP，URL，JSON以及XML。

参考资料
维基百科-Representational state transfer