点击“终码一生”，关注，置顶公众号
每日技术干货，第一时间送达！
故事还得从很多年前说起。
一、自由的野蛮生长期
此时，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 做到看接口地址即清楚接口实现的功能
五、故事结尾
本文的目的不是说个优劣，只是讲了个真实的故事。
来源：juejin.cn/post/7441057828544266250
往期推荐