REST风格的理解

目录

 

一、概念：

二、设计原则：

1.客户－服务器分隔：

2.无状态：

3.缓存：

4.统一接口：

5.分层系统：

6.按需代码：

三、传统结构和REST风格对比：

---

一、概念：

REST即表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构（一个 软件架构是一个软件系统在其操作的某个阶段的运行时（run-time）元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都有自己的软件架构。）风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

表达性状态传递是可以标识的资源（一个资源，一张图片，一份文档，一个服务，一个对象，甚至可以是一个操作流、可缓存文档）通过HTTP协议来传递，触发的是HTTP动作，这传递的状态是对应资源的状态，这状态是无记忆的，这动作携带的信息承载着操作资源所需要的所有信息，不管是GET、POST、PUT、PATCH、DELETE。对于一种操作，好像是一个不同的螺栓，用不同型号的扳手和辅助支撑，都是明确的套件；而传统的访问，是不加区分的，一个url对应的就是一个请求，至于用哪个HTTP动作，几乎没有任何套路，GET、POST靠个人的常规理解去应用的，url地址的拼接也是看项目团队的约定和开发人员的习惯，对于同一资源的同种操作，每个人哪怕是同一个开发不同模块需要操作的同一资源，通过HTTP协议承载的信息量也是不一样的，肯定是REST风格的子集，因为有同一Session域，或着前一个Request，甚至Application域内的共享信息。所以请求模式（请求地址-controller-model-数据库操作逻辑）哪怕相似，也不可复用。

基于以上的理解，REST这种架构风格可以形成一种套路吧，虽然不是标准，可以复用扩展的套路。那么也就为真正的前后端分离提供了可能性。

二、设计原则：

1.客户－服务器分隔：

分离关注点，用户的请求和服务器响应可以组成想到独立的组件，这也是中间件能顺利兼容、客户端和服务器职责分明，可以绑定在Angular、React、Vue等UI中间层上提供了可能性。

2.无状态：

请求必须携带服务器处理资源需要的全部信息，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用，那么session scope、application scope也就失去了它的价值。鱼与熊掌不可兼得嘛。

3.缓存：

请求响应承载的信息可以标记本次请求是否缓存，缓存可以为以后相同的请求重用这个响应的数据，响应速度提高了，但是启动缓存只适用于一致性要求不高，或最终一致性的环境，对于严格要求一致性和准实时一致性的环境则不适用。

4.统一接口：

客户和服务器之间通信的方法必须是统一化的，利用HTTP协议的基本特性动作：GET、POST、PUT、PATCH、DELETE。

（1）对于请求包括以下要素：

• 资源路径，如下例：

  GET https://www.alipay.com/customers/:id 

• HTTP动词，它定义了要执行的操作类型。

• 请求头部，它允许客户端传递关于请求的信息：

用于指定Accept字段的类型为MIME类型，它是由一个type和一个subtype通过斜线（/）分隔组成的。如image/png, image/jpeg, image/gif，application/json, application/pdf, application/xml, application/octet-stream。确保服务端不会发送客户端无法理解或者无法处理的数据。

• 包含数据的可选消息主体

（2）对于响应包括以下要素：

• 响应头：响应的content-type头域告诉客户端它在响应主体中发送的数据MIME类型以及响应状态（GET对应200,POST对应201，PUT对应200，DELETE对应204）
• 响应体

5.分层系统：

服务器和客户之间的通信必须符合这样的规则：允许服务器和客户之间的中间层（Ross：代理，网关等）担当代理角色，响应客户的请求。

6.按需代码：

服务器可以提供一些代码或者脚本在客户的运行环境中执行。

三、传统结构和REST风格对比：

传统结构：服务端数据体Model绑定渲染在View页面，对搜索引擎友好，这样做有利于 SEO，加载快于REST渲染；但实现复杂，不容易扩展，不够灵活。只有前端写完静态页面，后台接着套模板，不管是Freemarker还是JSP，每次前端稍有改动，后台对应的模板页面同时也需要改动，而且页面中可能会包含大量复杂的 逻辑性或着显示性的JS脚本。

REST风格：可以实现前后端完全分离，简单的CRUD操作，哪怕稍微复杂的操作，也可以通过组合方式实现。开发时前端和后端可以齐头并进。计算压力和请求压力都从服务器转移到前端和中间件上来缓冲处理了。另外也可以加入Node来实现部分模块代码的前后端复用。不过，在实现复杂操作时，需要在响应内容中包括下次操作需要的各种必要信息，显得有些多余。但是，这个缺点对于前后端分离这一大优势，不算太大的劣势。