mysql生成app接口_有没有这样的云服务：我只需定义好 mysql 的字段，就可以根据字段生成 restful api 了，我只需要写个前端 app 就行了？...

TommyLemon

2018-08-16 15:16:45 +08:00

@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