-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Home
接口全万能,前端不求人。要啥就有啥,所求即所得。
需求由它变,后端稳如山。不变应万变,上午就上线。
传统RESTful:返回不需要的字段、对象等
APIJSON:完全由请求指定返回内容,没有不需要的
传统RESTful:各种缩写、拼音、驼峰和非驼峰混用等,
只有看文档才知道是什么、才知道用哪个,而且文档还很可能有错误。
例如
评论数量可能是 commentCount, comment_count, cmt_count, pl_num...
分页页码可能是 page, pageNum, page_number, page_num, pnum...
APIJSON:常用的字段都已标准化,限制列表数量都用count,分页页码都用page,总数都用total
传统RESTful:对象为空时应该返回 null 或 {} ,但实际会返回空数组 [],
甚至是 "", "[]" 等 ,导致前端解析崩溃;
后端擅自改变类型导致线上App崩溃...
APIJSON:提供自动化API,所有字段对应值的类型都能保证是稳定的,
后端都不需要写代码也就不会去改变类型。
传统RESTful:各项目几乎完全不通用,不看相关的内部文档根本不知道对应的错误是什么,而且文档还很可能有错误。
例如
注册: 成功600, 手机号不合法601, 验证码错误603, 手机号已注册607, 缺少必要字段609...
评论: 成功1070, 不允许评论1071, 参数错误1073, 动态被删除1075...
APIJSON:只有十几个HTTP标准状态码,注释详细,即便不看注释网上一查也有一大堆正确的结果
传统RESTful:后端把接口改了没有及时通知,前端(客户端)莫名其妙调了半天才发现
APIJSON:可以用 APIAuto-机器学习HTTP接口工具 查看测试用例、以及表和字段的属性,
包括名称、类型、长度、默认值、注释等
传统RESTful:比如某个版本的QQ空间动态的JSON结构必须对应某个版本的某个接口,
有时候JSON结构甚至是由后端拍脑袋决定的,不好用也得用
APIJSON:完全由请求指定返回的JSON结构,即便UI变化也不需要对接口做任何更改
传统RESTful:为了兼容旧版应用不好直接改原来的接口,一般只能新增
APIJSON:查询不需要对接口做任何更改,增删改可用 Navicat, DataGrip, Workbench 等可视化工具
传统RESTful:前端(客户端)想要一次性返回或者更方便解析的结构,但后端想要少写代码
APIJSON:完全由前端(客户端)发的请求指定返回的JSON内容与结构,可任意组合任意嵌套,后端完全是自动解析不需要写代码
传统RESTful:delete忘加where直接删光全部数据,只要发生一次
APIJSON:对写操作强制要求指定id:1(单个)或id{}:[1,2,3](批量),并且自动校验权限
传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端(客户端)关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端(客户端)调用接口>(前端(客户端)关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端(客户端)解析返回结果>(前端(客户端)关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)
APIJSON:前端(客户端)调用接口>前端(客户端)解析返回结果
...
其它所有的接口开发库、框架、生成代码工具等,
不管是快速还是极速,就算是光速也没 APIJSON 快,
因为它们再怎么快也是要花时间的,
而用 APIJSON 开发接口根本就不用时间!
因为根本就不需要 编写或生成 接口!
需求一提出来就已经支持了,需求变更也不用修改代码或重新生成!
考虑实际情况下不仅要操作数据库,还要校验接口参数和用户权限等,以及需求不会覆盖排列组合嵌套的所有可能,
即便这样算下来 APIJSONBoot(按慢估计) 对比 SSM/SSH(按快估计) 等开发效率保守估计也都还能提升 20 倍以上
https://github.com/Tencent/APIJSON/issues/132
按照一般互联网中小型项目情况可得出以下对比表格:
表数量 T | 平均每表字段数 C | APIJSONBoot 按慢估计 | SSMH 按快估计 | APIJSONBoot 提速倍数 |
---|---|---|---|---|
1 | 3 | 11 min(约十分钟) | 179 min(约一上午) | 15.27 |
5 | 4 | 70 min(约一小时) | 1935 min(约朝九晚六一周) | 26.64 |
10 | 10 | 320 min(约一上午) | 8550 min(大小周超过半个月) | 25.72 |
20 | 15 | 940 min(约上班两天) | 31900 min(约 996 两个月) | 32.94 |
50 | 20 | 3100 min(约上班一周) | 176750 min(11117 超过半年) | 56.02 |
APIJSONORM 将 APIJSON 格式的请求 JSON 自动转换为 SQL 语句连接数据库并执行,
然后返回对应结构和内容的JSON,期间自动校验角色及对应的操作权限、自动防 SQL 注入。
(具体见 如何实现其它语言的 APIJSON? 以及开源中国 Gitee Meetup 的视频讲解 APIJSON-零代码接口和文档 ORM 库)
还可自动校验内容,比如在数据库配置
"VERIFY":{
"type{}":[0,1,2]
}
就能校验 type 的值是不是 0,1,2中的一个。
还有
"VERIFY": { "money&{}":">0,<=10000" } //自动验证是否 money>0 & money<=10000
"TYPE": { "balance": "DECIMAL" } //自动验证balance类型是否为BigDecimal
"UNIQUE": "phone" //强制phone的值为数据库中没有的
"MUST": "id,name" //强制传id,name两个字段
"REFUSE": "balance" //禁止传balance字段
"INSERT": { "@role": "OWNER" } //如果没传@role就自动添加
"UPDATE": { "id@": "User/id" } //强制放入键值对
全部操作符见 Operation.java 的注释
大体功能:
增删改查、分页排序、分组聚合、统计组合、模糊搜索、正则匹配、连续范围、比较运算、逻辑运算、
存储过程、各种JOIN、各种子查询、字段过滤、多数据库、跨库跨表、性能分析、排列组合、结构变换、
远程函数调用、多级缓存规则、数据与结构校验、角色与操作权限校验 等。
操作方式:
增、删、改、查、调用远程函数
操作对象:
单个对象、可关联的多个对象、数组等
请求方法:
GET,HEAD,GETS,HEADS,POST,PUT,DELETE
请求结构:
{ "Table":{...} }
{ "Table0":{...}, "Table1":{...}, "Table2":{...} ... }
{ "[]":{ "Table":{...} } }
{ "[]":{ "Table0":{...}, "Table1":{...}, "Array0[]":{...}, ... } }
等各种组合和嵌套
返回结构:
对应请求结构的各种JSON结构。
功能符号:
"key[]":{} // 查询数组
"key{}":[1,2,3] // 匹配选项范围
"key{}":"<=10;length(key)>1..." // 匹配条件范围
"key()":"function(arg0,arg1...)" // 远程调用函数
"key@":"key0/key1.../targetKey" // 引用赋值
"key$":"%abc%" // 模糊搜索
"key~":"^[0-9]+$" // 正则匹配
"key%":"2018-01-01,2018-10-01" // 连续范围
"key+":[1] // 增加/扩展
"key-":888.88 // 减少/去除
"name:alias" // 新建别名
"@combine":"name~,tag~" // 条件组合
"@column":"id,sex,name" // 返回字段
"@group":"userId" // 分组方式
"@having":"max(id)>=100" // 聚合函数
"@order":"date-,name+" // 排序方式
"@schema":"sys" // 集合空间
"@database":"POSTGRESQL" // 跨数据库
"@datasource":"DRUID" // 多数据源
"@explain":true // 性能分析
"@role":"LOGIN" // 访问角色
详细说明见通用文档中的 功能符
创作不易,右上角点 ⭐Star 支持下吧,谢谢 ^_^
https://github.com/Tencent/APIJSON