概述

REST是英文Representational State Transfer的缩写，中文翻译为“表述性状态转移”。是一种用于开发 Web 服务的体系结构样式。REST之所以受欢迎，是因为它的简单性，以及它建立在互联网超文本传输协议（HTTP）的现有系统和功能之上，以实现其目标，而不是创建新的标准，框架和技术。REST的一个独特之处在于，REST不要求开发人员使用自定义协议进行客户端-服务器消息交换，而是坚持认为实现基于网络的Web服务的最佳方法是使用网络协议本身的基本结构，就互联网而言，它就是HTTP。

使用REST的优点

• 从客户端和服务器的角度来看，使用 REST 的一个主要好处是，REST 交互基于习惯使用 HTTP 的任何人都熟悉的构造。REST 采用基于资源的方法，定义了开发人员与 Web 服务交互的方式。
• 基于 REST 的交互通过数字 HTTP 状态代码传达其状态。REST API 使用这些 HTTP 状态代码来检测错误并简化 API 监视过程
• 大多数开发人员已经熟悉 REST 体系结构的关键元素，例如SSL、TLS等安全及加密协议
• 在创建 RESTful API 或 Web 服务时，开发人员可以使用任何使用 HTTP 的语言来发出基于 Web 的请求。此功能使程序员可以轻松选择他们喜欢使用且最适合其需求的技术。
• REST 的普及是因为它在服务器端和客户端实现中的广泛使用。例如，在服务器端，开发人员可以使用基于 REST 的框架，包括 Restlet 和 Apache CXF。在客户端，开发人员可以使用各种框架（即jQuery，Node.js，Angular，EmberJS等），并使用内置于其API中的标准库调用RESTful Web服务。
• 在缓存方面，RESTful 服务采用有效的 HTTP 机制。例如，通过提供许多终结点，REST API 使开发人员能够更轻松地创建可满足特定部署需求的复杂查询

发展历史

Web在1993-1994年开始进入日常使用，当时一般用途的网站开始可用，当时，对Web架构的描述只有零散，业界也面临着就Web界面协议的一些标准达成一致的压力。例如，通信协议（HTTP）中增加了几个实验性的扩展来支持代理，并且正在提出更多的扩展，但是需要一个正式的Web体系结构来评估这些变化的影响

W3C 和 IETF 工作组一起开始着手创建 Web 的三个主要标准的正式描述：URI、HTTP 和 HTML。Roy Fielding参与了这些标准（特别是HTTP 1.0和1.1，以及URI）的创建，在接下来的六年中，他开发了REST架构风格，测试了它对Web协议标准的约束，并将其用作定义架构改进的手段 – 并识别架构不匹配。

2000年，Fielding在加州大学欧文分校的博士论文“架构风格和基于网络的软件架构的设计”中定义了REST。确定了在创建基于网络的全球范围的应用程序时适用的要求，例如需要较低的进入门槛才能实现全球采用。

协议标准

架构概念

REST 体系结构样式是为基于网络的应用程序（特别是客户端-服务器应用程序）而设计的。但更重要的是，它是为互联网规模的使用而设计的，因此用户代理 user agent（客户端）和源服务器 origin server之间的耦合必须尽可能轻量级（松散），以促进大规模采用。这是通过在服务器上创建一个抽象层来实现的，方法是定义封装服务器上的实体 entities（例如文件）的资源 resources，从而隐藏底层实现细节（文件服务器，数据库等）。但这个定义甚至比这更笼统：任何可以命名的信息都可以是一种资源：图像、数据库查询、时间服务（例如“今天的伦敦天气”），甚至是其他资源的集合。这种方法允许在跨越组织（信任）边界的长期互联网规模环境中客户端和服务器之间实现最大的互操作性。

客户端只能使用 URI 访问资源。换句话说，客户端使用 URI 请求资源，服务器使用资源的表示形式进行响应。资源的表示是REST中的另一个重要概念;为了确保响应可以由尽可能多的客户端应用程序解释，以超文本格式发送资源的表示形式，资源是通过在客户端和服务器之间的消息中传输的超文本表示来操作的。

架构属性

• 组件交互中的性能，这可能是用户感知性能和网络效率的主导因素;
• 可扩展性允许支持大量组件和组件之间的交互;
• 统一界面的简单性;
• 组件的可修改性以满足不断变化的需求（即使在应用程序运行时）;
• 服务代理对组件之间通信的可见性;
• 通过移动程序代码和数据来移植组件的可移植性;
• 在组件、连接器或数据中存在故障的情况下，在系统级抗故障的可靠性

架构规范

REST 体系结构样式定义了六个指导性规范。当这些规范应用于系统架构时，它获得了理想的非功能性属性，例如性能，可伸缩性，简单性，可修改性，可见性，可移植性和可靠性。符合部分或全部这些规范的系统被松散地称为RESTful。

客户端-服务器架构

将用户界面关注点与数据存储关注点分开，用户界面的可移植性得到了改善。这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能

无状态性：

即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。当然也由于没有上下文的支持，而导致资源的浪费。

统一接口

统一接口是任何RESTful系统设计的基础。它简化并解耦了架构，使每个部分都能独立演进。此统一接口的四个规范是：

• 请求中的资源标识 – 在请求中标识单个资源，例如，在 RESTful Web 服务中使用 URI
• 通过表示进行资源操作
• 自我描述性消息 – 每条消息都包含足够的信息来描述如何处理消息
• 在访问了 REST 应用程序的初始 URI（类似于访问网站主页的人类 Web 用户）之后，REST 客户端应该能够动态地使用服务器提供的链接来发现它需要的所有可用资源

可缓存性

客户端和中介可以缓存响应。响应必须隐式或显式地将自身定义为可缓存或不可缓存，以防止客户端提供过时或不适当的数据来响应进一步的请求。管理良好的缓存可以部分或完全消除一些客户端-服务器交互，从而进一步提高可伸缩性和性能。缓存可以在客户端计算机的内存或浏览器缓存存储中执行

分层系统

客户端通常无法判断它是直接连接到终端服务器还是连接到中间服务器。如果在客户端和服务器之间放置代理或负载平衡器，则不会影响它们的通信，也不需要更新客户端或服务器代码。中间服务器可以通过启用负载平衡和提供共享缓存来提高系统可伸缩性

按需编码

REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束

操作资源

对于如何操作资源，有相应的HTTP动词对应，常见的动词有如下五个（括号里表示SQL对应的命令）：

GET（SELECT）：从服务器取出资源（一项或多项）
POST（CREATE）：在服务器新建一个资源
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）
DELETE（DELETE）：从服务器删除资源