表现层状态转换（REST，英文：Representational State Transfer）是Roy Thomas Fielding（英语：Roy Thomas Fielding）博士于2000年在他的博士论文中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中互相传递信息。表现层状态转换（REST，英文：Representational State Transfer）是根基于超文本传输协议(HTTP)之上而确定的一组约束和属性，是一种设计提供万维网络服务的软件构建风格。匹配或兼容于这种架构风格(简称为 REST 或 RESTful)的网络服务，允许客户端发出以统一资源标识符访问和操作网络资源的请求，而与预先定义好的无状态操作集一致化。因此表现层状态转换提供了在互联网络的计算系统之间，彼此资源可交互使用的协作性质(interoperability)。相对于种类的网络服务，例如 SOAP服务则是以本身所定义的操作集，来访问网络上的资源。目前在三种主流的Web服务实现方案中，因为REST模式与复杂的SOAP和XML-RPC相比更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务运行图书查询；雅虎提供的Web服务也是REST风格的。

需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。

资源是由URI来指定。 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。 通过操作资源的表现形式来操作资源。 资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。 可重新表达的状态迁移的特征 统一接口(Uniform Interface)

1. 以资源为基础

每个资源都可以通过URI访问到。

也就是一个个可以认知的资源，比如文档，音乐，视频等信息，都可以通过唯一的URI确定

2. 通过重表达的客户端可以管理原资源

就是我们通过客户端可以修改原资源的状态

3. 返回信息足够描述自己

这样重表达的客户端可以知道如何处理

4. 超媒体是应用状态的引擎

处理以超媒体为基础的状态变化

Stateless

无状态

Cacheable

可缓存

Client-Server

客户服务器分离模式，任何一个客户端与服务器都是可替换的

Layered System

分层的系统，客户端不知道他联系的是不是最终服务器

Code on Demand (OPTional)

服务器可以将能力扩展到客户端，如果客户端可以执行的话。这个功能是可选择的。

具体说明

REST架构风格最重要的架构约束有6个：

客户-服务器（Client-Server） 通信只能由客户端单方面发起，表现为请求-响应的形式。 无状态（Stateless） 通信的会话状态（Session State）应该全部由客户端负责维护。 缓存（Cache） 响应内容可以在通信链的某处被缓存，以改善网络效率。 统一接口（Uniform Interface） 通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。 分层系统（Layered System） 通过限制组件的行为（即每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。 按需代码（Code-On-Demand，可选） 支持通过下载并执行一些代码（例如Java applet、Flash或JavaScript），对客户端的功能进行扩展。

应该注意区别应用的状态和连接协议的状态。HTTP连接是无状态的（也就是不记录每个连接的信息），而REST传输会包含应用的所有状态信息，因此可以大幅降低对HTTP连接的重复请求资源消耗。

应用于Web服务

匹配REST设计风格的Web API称为RESTful API。它从以下三个方面资源进行定义：

直观简短的资源地址：URI，比如：http://example.com/resources/。 传输的资源：Web服务接受与返回的互联网媒体类型，比如：JSON，XML，YAML等。 对资源的操作：Web服务在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。

下表列出了在实现RESTful API时HTTP请求方法的典型用途。

HTTP请求方法在RESTful API中的典型应用[3] 资源 GET PUT POST DELETE 一组资源的URI，比如https://example.com/resources/ 列出URI，以及该资源组中每个资源的详细信息（后者可选）。 使用给定的一组资源替换当前整组资源。 在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。 删除整组资源。 单个资源的URI，比如https://example.com/resources/142 获取指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等） 替换/创建指定的资源。并将其追加到相应的资源组中。 把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源。 删除指定的元素。

PUT和DELETE方法是幂等方法。GET方法是安全方法（不会对服务器端有修改，因此当然也是幂等的）。

不像基于SOAP的Web服务，RESTful Web服务并没有“正式”的标准。这是因为REST是一种架构，而SOAP只是一个协议。虽然REST不是一个标准，但大部分RESTful Web服务实现会使用HTTP、URI、JSON和XML等各种标准。

可更高效利用缓存来提高响应速度 通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性 浏览器即可作为客户端，简化软件需求 相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小 不需要额外的资源发现机制 在软件技术演进中的长期的兼容性更好