什么是 RESTful

在看项目时,常常会发现某个项目采用 RESTful API 实现前后端分离。那么到底什么是 RESTful 呢?

什么是 RESTful

一种架构风格。(是风格而不是标准)
RESTful 是指满足 REST 原则的意思。
如果一个架构符合REST原则,那么就可以称之为RESTful架构。
问题又来了, 这个 REST 又是什么呢?

什么是 REST

理解 RESTful 架构

REST, 即Representational State Transfer。翻译为表现层状态转化。实际指资源的表现层状态转化。

资源 (Resources)

指网络上的一个实体或网络上的具体信息。可以通过 URI (统一资源定位符) 定位它。

URI = scheme “://“ authority “/“ path [ “?” query ][ “#” fragment ]

  • scheme: 指底层用的协议,如http、https、ftp
  • host: 服务器的IP地址或者域名
  • port: 端口,http中默认80
  • path: 访问资源的路径,就是咱们各种web 框架中定义的route路由
  • query: 为发送给服务器的参数
  • fragment: 锚点,定位到页面的资源,锚点为资源id

表现层 (Representation)

我们把”资源”呈现出来的形式,叫做它的”表现层”。
URI只代表资源的实体,不代表它的形式。严格地说,有些网址最后的”.html”后缀名是不必要的,因为这个后缀名表示格式,属于”表现层”范畴,而URI应该只代表”资源”的位置。它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对”表现层”的描述。

状态转化 (State Transfer)

互联网通信协议HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生”状态转化”(State Transfer)。而这种转化是建立在表现层之上的,所以就是”表现层状态转化”。

  • GET 获取资源 幂等
  • POST 新建资源(也可用于更新资源)非幂等
  • PUT 更新资源 幂等
  • PATCH 更新局部资源 非幂等
  • DELETE 删除资源 幂等
  • HEAD 获取资源的元数据 幂等
  • OPTIONS 获取信息,关于资源的哪些属性是客户端可以改变的 幂等

虽然PUT也是更新资源,但是要求前端提供的一定是一个完整的资源对象。按照约定,如果使用 PUT,却没有提供完整的对象数据,缺失的部分应该被清空

思考: 为什么 PUT 是幂等的,但是 PATCH 却不是幂等的呢?

REST的指导原则

  1. 客户端 - 服务器 - 通过将用户接口问题与数据存储问题分开,我们通过简化服务器组件来提高跨多个平台的用户接口的可移植性并提高可伸缩性。
  2. 无状态 - 从客户端到服务器的每个请求都必须包含理解请求所需的所有信息,并且不能利用服务器上任何存储的上下文。因此,会话状态完全保留在客户端上。
  3. 可缓存 - 缓存约束要求将对请求的响应中的数据隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的,则客户端缓存有权重用该响应数据以用于以后的等效请求。
  4. 统一接口 - 通过将通用性的软件工程原理应用于组件接口,简化了整个系统架构,提高了交互的可见性。为了获得统一的接口,需要多个架构约束来指导组件的行为。REST由四个接口约束定义:资源识别; 通过陈述来处理资源; 自我描述性的信息; 并且,超媒体作为应用程序状态的引擎。
  5. 分层系统 - 分层系统风格允许通过约束组件行为来使体系结构由分层层组成,这样每个组件都不能“看到”超出与它们交互的直接层。
  6. 按需编码(可选) - REST允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。这通过减少预先实现所需的功能数量来简化客户端。

注意事项

  1. URI 不应包含动词。因为”资源”表示一种实体,所以应该是名词(最好为名词复数形式),URI不应该有动词,动词应该放在HTTP协议中。
  2. URI 中不应该加入版本号。因为不同的版本,可以理解成同一种资源的不同表现形式,所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分。

缺点

  • 基于资源型的RESTFul API接口粒度和返回结果过于的“粗”,它通常返回的都是完整的数据模型,这对于客户端非常不友好。
  • 某些业务情况下,可能存在请求多次接口。造成整体响应时间过长。
咸鱼也要有梦想,万一实现了呢
0%