问题描述

在 REST 出现之前，URI被随意命名，URI 不统一。

如下为没有风格约束的 URI 信息，如下示例：
1）预约会议室：/reserve/meetingroom/B25R
2）取消预约会议室：/cancel/meetingroom/B25R
3）查询会议室状态：/meetingroom/B25R?method=query

解决方案

2000 年，HTTP 的主要设计者 Roy Thomas Fielding 发布的博士论文提出 REST 风格。REST（Representational State Transfer，表述性状态转化）资源在网络中以某种表现形式进行状态转化，是一种软件架构风格。简而言之，REST是一种设计风格。

REST的全称“ Representational State Transfer ”，表现层状态转化，实际上省略了主体资源。

Roy论文《Architectural Styles and the Design of Network-based Software Architectures》摘要：”本文研究计算机科学的两大前沿-软件和网络的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。”

URI 是统一资源标识符，它标识资源的具体位置，所以在 URI 中不应该包含动作。REST 规范 URI 命名，面向资源，一目了然。

原理简述

REST 作为客户端-服务器的交互框架，具有三个概念：资源；表现层；状态转化；

资源：URI定位资源

“资源”是一个信息实体。网络上的所有事物都可被抽象为资源，每个资源都有一个唯一的资源标识符（URI）。例如端口、网元、单板、机房等都属于资源。

REST 的核心在于资源和操作。用URI定位资源，用 HTTP 动作（GET, POST, PUT, DELETE）描述操作。

表现层：各种格式标识资源

“资源”具有多种外在表现形式，“资源”具体呈现出来的形式，叫做它的“表现层”（Representation）。

例如：文本作为资源可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式表现。图片作为资源可以用JPG格式表现，也可以用PNG格式表现等等。

状态转化：HTTP动作进行CRUD操作

访问一个URI，即代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端，客户端不保存状态。因此，客户端通过”某种手段“（就是HTTP协议）操作服务器，让服务器端发生“状态转化”（State Transfer）。而这种转化是依赖表现层的，所以就是“表现层状态转化”。

特性特征

在 REST 出现之后： URI 独立，动作清晰；

具有 REST 风格的 URI 信息，如下示例：
预约会议室：/meetingroom/B25R，调用方法为POST
取消预约会议室：/meetingroom/B25R，调用方法为DELETE
查询会议室状态：/meetingroom/B25R，调用方法为GET

设计概念及准则

网络上的所有事物都可被抽象为资源。
每一个资源都有唯一的资源标识，对资源的操作不会改变这些标识。
使用标准方法操作资源，核心操作为HTTP规范定义的GET，PUT，POST，DELETE。
所有的操作都是无状态的。

充分利用 HTTP 协议

以上这些字段全都存在于HTTP报文中，可见REST充分利用或者说极端依赖HTTP协议。

RESTful API

API（Application Programming Interface，应用编程接口）：指应用程序之间为了保证互相通讯所提供的一系列特殊规则和要求。

RESTful 接口是遵循 REST 设计风格的接口。RESTful 接口没有标准的强制性要求，定义起来相对自由。
符合 REST 架构风格的 API 便是 RESTful API；

目前 Restful API 的实现使用 HTTP 的标准规范，所以这里将 RESTful API 与 HTTP 进行关联；

接口演进：无状态设计

REST 采用无状态设计，提高系统的可扩展性。

状态化请求、有状态：服务端需要保存和维护先前请求的状态信息，后面的每一个状态都依赖于先前状态。服务器端一般都要保存请求的相关信息，每个请求可以默认地使用以前的请求信息。

有状态无状态混杂导致客户端需要多次请求信息才能获得需要的结果。流程繁琐影响用户体验。没有一个URI能够直接定位。
如登陆OA查看工资需要经过多个步骤：登陆OA -> 进入个人中心 -> 进入薪资查询 -> 查看工资

无状态请求、无状态：服务端每次对相同的请求，函数或方法调用都给出相同的响应，不依赖于其他请求。服务端不需要维护状态信息，更易扩展。每个资源都是可寻址的，至少有一个URI对其定位。服务器端的处理结果必须全部来自于一次请求所携带的信息。

在 REST 架构下，一次请求就可以获得需要的结果，如工资可以直接通过以下URI查询：
张三工资：http://oa.company.com/salary/zhangsan
李四工资：http://oa.company.com/salary/lisi

接口演进：前后端分离

REST 跨平台兼容性好，实现了前后端分离。
前端主要涉及用户所能看到的展示界面。
后端主要涉及数据处理的逻辑功能。

REST出现之前：前后端紧耦合

早期的Web项目一般是在服务端进行渲染，客户端直接获得服务端渲染后的视图并与之交互。

优点：前端只需要一次请求即可以返回整个页面内容，加载速度快。
缺点：各组件紧密关联，前端视图的修改需要同步修改后端各逻辑模块。

REST出现之后：前后端分离

REST发展的关键原因是移动互联网的出现。由于多终端设备的兼容性需求，从前的服务端渲染难以满足移动互联网要求。服务端不可能针对每一个客户端渲染一套界面，因此催生了REST的发展和普及。

通过REST，服务端只处理数据，而具体界面的渲染交给客户端来完成，实现了前后端分离。

REST风格接口RESTful API为各终端提供统一的界面，这是传统的接口所不擅长的。