@
wangxiaoaer 后端：零用时开发接口、零沟通零被打扰。
前端 /客户端：内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。
后端不用写接口、也不用写文档就能提供"接口"和"文档"，前端 /客户端不用看"文档"就能调用"接口"。
APIJSON 实现了前端 /客户端要什么就返回什么，而不是后端给什么才能用什么，从根本上解决了：
1.浪费性能、流量和带宽
传统 RESTful：返回不需要的字段、对象等
APIJSON：完全由请求指定返回内容，没有不需要的
2.各种奇葩的缩写、混乱的命名
传统 RESTful：各种缩写、拼音、驼峰和非驼峰混用等，只有看文档才知道是什么、才知道用哪个，而且文档还很可能有错误。
例如
评论数量可能是 commentCount, comment_count, cmt_count, pl_num...
分页页码可能是 page, pageNum, page_number, page_num, pnum...
APIJSON：常用的字段都已标准化，限制列表数量都用 count，分页页码都用 page，总数都用 total
3.几百甚至上千个混乱的状态码
传统 RESTful：各项目几乎完全不通用，不看相关的内部文档根本不知道对应的错误是什么，而且文档还很可能有错误。
例如
注册: 成功 600, 手机号不合法 601, 验证码错误 603, 手机号已注册 607, 缺少必要字段 609...
评论: 成功 1070, 不允许评论 1071, 参数错误 1073, 动态被删除 1075...
APIJSON：只有十几个 HTTP 标准状态码，注释详细，即便不看注释网上一查也有一大堆正确的结果
4.文档过时，与接口不同步
传统 RESTful：后端把接口改了没有及时通知，前端 /客户端莫名其妙调了半天才发现
APIJSON：可以用 APIJSONAuto 在线工具 查看测试用例、以及表和字段的属性，包括名称、类型、长度、默认值、注释等
5.应用界面和接口强耦合难分离
传统 RESTful：比如某个版本的 QQ 空间动态的 JSON 结构必须对应某个版本的某个接口，有时候 JSON 结构甚至是由后端拍脑袋决定的，不好用也得用
APIJSON：完全由请求指定返回的 JSON 结构，即便 UI 变化也不需要对接口做任何更改
6.版本迭代导致大量重复功能的接口
传统 RESTful：为了兼容旧版应用不好直接改原来的接口，一般只能新增
APIJSON：查询不需要对接口做任何更改，增删改可用 WorkBench 等可视化工具
7.前端 /客户端与后端扯皮
传统 RESTful：前端 /客户端想要一次性返回或者更方便解析的结构，但后端想要少写代码
APIJSON：完全由前端 /客户端发的请求指定返回的 JSON 内容与结构，可任意组合任意嵌套，后端完全是自动解析不需要写代码
8.数据库操作不安全
传统 RESTful：delete 忘加 where 直接删光全部数据，只要发生一次
APIJSON：对写操作强制要求指定 id:1(单个)或 id{}:[1,2,3](批量)，并且自动校验权限
9.开发流程繁琐周期长
传统 RESTful：后端写接口>后端写文档>前端 /客户端查文档>(前端 /客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端调用接口>(前端 /客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端解析返回结果>(前端 /客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)
APIJSON：前端 /客户端调用接口>前端 /客户端解析返回结果
为什么要用 APIJSON ？或者 APIJSON 有什么用？
https://github.com/TommyLemon/APIJSON/wiki