前言

可能很多近几年入行的小伙伴只知道前端用 Vue/React 之类的框架，后端用 Go/Java 等适合写服务端的语言。

然后前端调用后端写好的接口，拿到接口返回的 JSON 数据就行。

但是却并不知道是如何进化为当前这种开发模式的！

这里提到了接口和 JSON 数据，这两点就跟如今盛行的 RESTful API 强相关，我们下文会仔细聊到的。在此之前，我们先简单聊一聊网站的的开发模式是怎么样进化的：

考古一下

其实在很多年前，网站开发大致经历了如下的阶段（以 Java 为例啊，毕竟后端我就 Java 熟悉一点点）

后端为王，前端切图仔时代

Struts + Spring
Spring MVC (JSP) + Mybatis

这个时代的经典识别标志就是：JSP、SSH、SSM、模板引擎

时间节点大概在：15年前

前后端分离时代

Spring Boot + Spring MVC (RESTful) + EasyUI 或者 Layui

这个时代的经典识别标志就是：Ajax、RESTful API、JSON

时间节点大概在：10年前

前端崛起

Spring Boot + Spring MVC (RESTful) + Spring Cloud + Vue 或 React

这个时代的经典识别标志就是：Vue、React、前端工程化

时间节点大概在：当下

RESTful API

可以从开发模式的进化中看见，RESTful 风格的 API 其实早在 10 年前就开始运用，而如果你现在都不会的话，你就应该赶紧学学了...

定义

RESTful API 更多的只是一种风格，并不是强制的，毕竟 RESTful 风格的请求依旧是属于标准的 HTTP 请求

规则

RESTful 风格将图片、文本、服务等具体信息都看做资源，并创建一个唯一的 URI 指向它，想要获取资源，调用这个唯一 URI 就可以了
该资源具体是什么样的表现形式，用 Accept 和 Content-Type 字段来定义，比如我们想要 JSON 数据，就可以将 Content-Type 设置为 application/json
RESTful 风格中 GET 用来获取资源，POST 用来新建资源，PUT 用来更新资源，DELETE 用来删除资源

经典的错误设计

假如我们要获取博客中第一篇文章，按照 RESTful 风格，你可以设计为：/blog/1 并且请求方法采用 GET

而经典的错误设计是：/blog/get/1，因为你将 获取 这个动词放到了 URI 上，这样其实就和请求方法采用 GET 动词重复了

实践

约定前后端采用 JSON 格式进行数据传递，所以：

请求的 Content-Type 要设置为 application/json
响应的 Content-Type 也要设置为 application/json
除 GET 请求外，POST、PUT、DELETE 等请求的 Body 是 JSON 数据格式

约定 HTTP 状态码和业务状态码规则：

状态码严格遵循标准的 HTTP 状态码
统一响应数据格式，并返回业务状态码

统一响应格式大家现在一般采用这种格式

{
  code: number
  data: any
  message: string
}

其中 code 就是业务状态码，它是团队内部自行设定的，比如 code 为 0 代表一切正常，1001 代表某某业务出现问题。

经典的错误实践

但是但是但是，我发现有很多朋友是这样错误运用 HTTP 状态码和业务状态码的：

前端一个请求发过去，后端首先返回 HTTP 状态码为代表成功的 200，然后响应数据里的业务状态码却返回了代表错误的 500。

这其实是不太规范的，这种情况就好像在说 “你的请求成功了，但其实最终还是出错了...”

是不是有点无厘头，所以我们应该严格遵守标准的 HTTP 状态码，这种情况应该直接采用 HTTP 状态码 500。

简单来说就是，率先使用 HTTP 状态码，当 HTTP 状态码都不够用或者不满足时（多半是出现特殊的业务问题时）才用业务状态码来做判断。

什么情况下全部返回 200？

有一种情况就是，你返回的 HTTP 状态码不为 200 时，可能会被运营商、路由器等节点劫持，并将你的页面重定向到其他未知页面。

这种时候，你可能就需要全部返回 200，然后在业务状态码里面进行区分成功与否了。

当然，现在是 HTTPS 时代，我更建议你直接上 HTTPS 来杜绝这个问题。

被人诟病的问题

动词问题

因为 RESTful 风格中一个 URI 对应一个资源，所以风格上不允许 URI 包含动词，应该全是名词。

就比如前文提到的常见的错误设计：/blog/get/1，因为你将 获取（get） 这个动词放到了 URI 上，这样其实就和请求方法采用 GET 动词重复了，是不符合规范的。

有人就觉得开发一个 API 还有这种无理的需求，简直是耽误时间。

资源问题

比如登录/登出，用 RESTful 风格的话，你很难将其抽象成资源，如果你用 POST 请求方法和 /login 路径，这就显然是不太符合 RESTful 风格了

但实际上大家基本上都选择无视这一点，依旧正常采用 POST 请求方法和 /login 路径

个人看法

怎么说呢，我个人觉得 RESTful 风格还是非常的好的，它能有效规范团队开发出来的接口，并且它不是强制的，如果你觉得动词问题或者资源问题让你非常难受，那你也可以在必要时不遵守这些点（学会变通也是非常重要的）

最后

其实除了 RESTful 风格，还有 RPC 风格的。

比如上面提到的被诟病的问题，在 RPC 风格中是不存在的，但这并不是 RPC 风格就优于 RESTful 风格，只能说萝卜青菜各有所爱吧~

✒️ 带你了解前后端进化史 与 RESTful API 的出现

前言