主要观点总结
文章主要讲述了一个关于后端技术团队在API设计过程中所面临的挑战和变革的故事。从最初的自由野蛮生长期，到尝试遵循Restful规范，再到面临各种问题和挑战后决定抛弃Restful规范，最终形成了自己的设计理念和规范的过程。
关键观点总结
关键观点1: 文章介绍了团队初期通过约定API返回数据的JSON格式和HTTP状态码来标识后端服务状态。
此时存在的问题是缺乏统一的错误代码标准规范，失败的错误代码混乱。
关键观点2: 团队尝试遵循Restful规范，但在实际操作中遇到了HTTP状态码不够用和HTTP资源边界处理混乱的问题。
为了解决这些问题，团队采取了扩展HTTP状态码和使用抽象资源的方法，但这些问题并没有得到根本解决。
关键观点3: 架构师的离开和项目上线后出现的问题，使得团队面临新的挑战。
客服反映某些资源访问问题以及HTTPS的实施和小程序开发中对Restful规范的挑战。
关键观点4: 团队决定抛弃Restful规范，采用新的设计理念和规范。
包括使用POST一把梭、恢复野蛮发展期的数据格式、新的状态码规则和接口命名新标准等。
文章预览
故事还得从很多年前说起。 一、自由的野蛮生长期 此时，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 表
………………………………
