⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7441057828544266250 「Hamm」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

故事还得从很多年前说起。

一、自由的野蛮生长期

此时,ajax,刚出生。

我们通过约定了 API 返回数据的 JSON 格式如下:

{
"code": 0,
"msg": "SUCCESS",
"data": DATA // {},[],null,string,boolean,number
}

然后,HTTP部分使用 HTTP 状态码 200 来表示后端服务正常运行。

问题不是很大,成功还好,状态码是 0。

但因为没有制定统一的错误代码标准规范,失败的错误代码乱七八糟,只有一个 401 很特殊,表示你的身份过期了需要重新登录。其他的基本是 1 一把梭,表示有问题,具体什么问题,自己猜。。。

二、后来来了个架构师

说要正确的拥抱 Restful ,所以尊重 HTTP 规范中的 状态码定义,例如:

  • 200 OK 表示操作或者查询成功
  • 400 Bad Request 表示请求参数有误
  • 401 Unauthorized 表示用户未登录或者登录的令牌过期
  • 403 Forbidden 表示用户没有权限
  • 404 Not Found 表示请求的资源不存在

基于 Restful 规范,返回的 BODY 部分往往都是具体的数据,不会再使用 JSON 再给包一次。

随着团队人数的增多、业务需求的复杂和变更、团队成员参差不齐,基于 Restful 风格的标准又开始乱了:

2.1 HTTP错误代码不够用

问架构师,他说 “你就用 601 表示吧, http状态码又不是不可以扩展。”

嗯,那就扩展吧,于是有了下面这个图:

然后过了段时间,炸了。后端给了个状态码 1001,和 2001,表示两个错误,到了前端就炸了。

http 状态码最大 999 再大就会被截断成三位。比如上面的 2001 响应后,就会变成 200。

咦,后端有错误,到响应前端后成了 成功 了?

2.2 HTTP资源边界处理太乱

用户登录该放到哪个资源下?

问架构师,他说 “你不会抽象吗?你抽象个登录记录出来,添加登录记录,不就是登录接口了吗?”

嗯,那就抽象吧,于是出现一堆 _log 的资源,比如 login_log。有的是有真实的表存储的,有的又是假的,只用来满足 Restful 规范的。

三、架构师跑路了

架构师受不了上面的一些问题被天天骚扰,跑路了。现在没人提问没有人支持了。

3.1 项目总算上线了

你以为故事就这么结束了?幺蛾子总是在不经意间飞来飞去。

客服:“**省的电信用户,访问某个不存在的资源就闪退”

??????

好家伙,一远程查看了下,发现客户那边只要是404,就都被劫持成了另外一个页面。

宝*回家??

好好好,架构师没说这事,于是一直是 HTTP 在跑,那上个 HTTPS 吧。

3.2 开始做小程序了

开始做微信小程序了,然后发现,Restful 炸了。

微信小程序不支持 PATCH 请求。 于是我们在 PUT 上加了一个 _method 参数,用来告诉后端,我要用 PATCH 请求。

乱了乱了。

四、后现代文艺复兴

后来重构了项目,我们考虑了很久(大概十几秒),决定抛弃 Restful 规范。

4.1 使用POST一把梭

所有参数都使用 POST 传递(除部分下载和导出之外),懒得纠结该用什么方法了。

4.2 恢复野蛮发展期的数据格式

{
"code": 200,
"message": "SUCCESS",
"data": DATA // {},[],null,string,boolean,number
}

但使用下面行的状态码规则。

4.3 新的状态码规则

整体还是尊重了 HTTP 规范,使用 200 表示成功,其他表示失败,但也不是完全定死的。

但一定使用统一的枚举实现:

比如 403 表示无权限的大类,但可以继续往后扩展 4031 表示没权限创建等等。

4.4 接口命名新标准

使用 动词 + 形容词 + 资源名称 的方式来定义一个接口,如 getUserInfo updateOrderStatus addMyOrder, deleteAllLog 做到看接口地址即清楚接口实现的功能

五、故事结尾

本文的目的不是说个优劣,只是讲了个真实的故事。

文章目录
  1. 1. 一、自由的野蛮生长期
  2. 2. 二、后来来了个架构师
    1. 2.1. 2.1 HTTP错误代码不够用
    2. 2.2. 2.2 HTTP资源边界处理太乱
  3. 3. 三、架构师跑路了
    1. 3.1. 3.1 项目总算上线了
    2. 3.2. 3.2 开始做小程序了
  4. 4. 四、后现代文艺复兴
    1. 4.1. 4.1 使用POST一把梭
    2. 4.2. 4.2 恢复野蛮发展期的数据格式
    3. 4.3. 4.3 新的状态码规则
    4. 4.4. 4.4 接口命名新标准
  5. 5. 五、故事结尾