部分功能描述可在 APIAuto 上查看
账号 13000002020 密码 123456
http://apijson.org:8000/auto/
1.一定要有相关的应用场景,不能是伪需求,最好举例说明
2.能用 远程函数 或者 @raw 等现有功能很好地实现的,都不新增,避免冗余
3.不影响现有功能的使用,不能让现有功能不可用或者使用更复杂
一般对于互联网项目,数据非常重要,基本不会物理删除,
只是用 is_deleted 等字段来标记已删除,然后 CRUD 时默认过滤已标记的记录。
这个功能非常必要,可以通过重写 SQLConfig.isFakeDelete() 来标记,
然后如果 true,则把 DELETE 改为 PUT 并且通过重写
SQLConfig.onFakeDelete(Map<String, Object> map) 来新增条件:
GET: map.put("deleted", 0)
PUT: map.put("deleted", 0)
DELETE: map.put("deleted", 1)
POST: 用不上,不处理
当然也可以再加一个删除时间 deletedTime 之类的。
还可以在 apijson-framework 层支持 Access 表新增字段 deletedKey, deletedValue, notDeletedValue,
然后读表自动配置是否为假删除 StringUtil.isNotEmpty(deletedKey, true) ,是假删除时 put 相应键值对。
来实现内部条件 AND 连接,原来的 @having 由 AND 连接变为 OR 连接,保持 横或纵与 的统一规则。
@having! 必须性不大,可通过反转内部条件来实现,但如果实现简单、且不影响原来的功能,则可以顺便加上。
这个只在 apijson-framework 支持,需要配置每个接口版本、每张表所拥有的全部字段,然后排除掉 @column! 的。
可新增一个 VersionedColumn 表记录来代替 HashMap 代码配置。
需要注意的是,可能前端传参里既有 @column 又有 @column! ,碰到这种情况:
如果没有重合字段就忽略 @column! ,只让 @column 生效;
如果有有重合字段,则抛异常,转为错误码和错误信息返回。
目前 APIJSON 支持 Oracle 和 SQL Server 这两种 TSQL 数据库(群友测试 IBM DB2 也行)。
但是 "@explain": true 使用的是 SET STATISTICS PROFILE ON(具体见 AbstractSQLConfig 和 AbstrctSQLExecutor)
执行后居然是 SELECT 查到的放在默认的 ResultSet,性能分析放在 moreResult,
因为这个问题目前以上两个数据库的性能分析 @explain 实际并不可用,需要改用其它方式或解决现有方式的 bug。
目前只能从 0 开始,实际使用 1 更广泛,而且这方面用户习惯很强,支持它成本也不高。
Parser 新增 DEFAULT_QUERY_PAGE 和 getDefaultQueryPage,
与 DEFAULT_QUERY_COUNT 和 getDefaultQueryCount 统一,
方便前端直接用页码的值传参,以及 info.page 的值来渲染页码。
建议在 AbstractParser,AbstractSQLConfig 用到 page 的地方判断 getDefaultQueryPage,做兼容处理。
"@url": "http://apijson.cn:8080/get"
{
"User": {
"@url": "http://apijson.cn:8080/get" //转发给其它服务器执行
},
"[]": {
"Comment": {
"userId@": "User/id"
}
},
"@explain": true
}
考虑到引用赋值的依赖关系要保持先后顺序,必须同步阻塞处理。
或许可以加一个 ~ 前缀表示异步?例如 "@url": "~http://apijson.cn:8080/get",由调用方保证没有被下方对象依赖。
虽然可以通过 INNER JOIN + 条件 OR 连接来替代它的功能,但没法达到它能用索引的性能。
支持 UNION 很有必要,但 UNION ALL 几乎没有需求,如果实现简单、且不影响原来的功能,则可以顺便加上。
"@union": Integer // 0 - 不使用,1 - UNION,2 - UNION ALL
{
"[]": {
"User": {
"name~": "a",
"tag~": "a",
"@combine": "name~,tag~",
"@union": 1 //将 @combine 中的 N 个 OR 连接字段用 UNION 替换,原本一条 SQL 需要拆分成 N 条 SQL 来 UNION
}
},
"@explain": true
}
生成的 SQL
SELECT * FROM `sys`.`apijson_user` WHERE ( (`name` REGEXP BINARY 'a') OR (`tag` REGEXP BINARY 'a') ) LIMIT 10 OFFSET 0
需要变为
SELECT * FROM `sys`.`apijson_user` WHERE ( (`name` REGEXP BINARY 'a') )
UNION
SELECT * FROM `sys`.`apijson_user` WHERE ( (`tag` REGEXP BINARY 'a') )
LIMIT 10 OFFSET 0
可以减少子查询执行次数,提高性能。
{ //看看关注的人最近有什么动态(分享、评论)
"sql@": {
"with": true, //生成 WITH(SELECT id ...) AS `sql`
"from": "User",
"User": {
"@column": "id",
"@role": "CONTACT"
}
},
"Moment[]": {
"Moment": {
"userId{}@": "sql",
"@order": "date-"
}
},
"Comment[]": {
"Comment": {
"userId{}@": "sql",
"@order": "date-"
}
},
"@explain": true
}
生成的 SQL
SELECT * FROM `sys`.`Moment` WHERE ( (`userId` IN (SELECT `id` FROM `sys`.`User` WHERE `id` IN($contactIdList)) ) ) ORDER BY `date` DESC LIMIT 10 OFFSET 0
和
SELECT * FROM `sys`.`Moment` WHERE ( (`userId` IN (SELECT `id` FROM `sys`.`User` WHERE `id` IN($contactIdList)) ) ) ORDER BY `date` DESC LIMIT 10 OFFSET 0
需要变为
WITH (SELECT `id` FROM `sys`.`User` WHERE `id` IN($contactIdList)) AS `sql`
SELECT * FROM `sys`.`Moment` WHERE ( (`userId` IN `sql` ) ) ORDER BY `date` DESC LIMIT 10 OFFSET 0
和
WITH (SELECT `id` FROM `sys`.`User` WHERE `id` IN($contactIdList)) AS `sql`
SELECT * FROM `sys`.`Comment` WHERE ( (`userId` IN `sql` ) ) ORDER BY `date` DESC LIMIT 10 OFFSET 0
【更新:不用实现了,直接按 SQL 的语法写 CASE WHEN,然后用 @raw】
实现远程函数也不方便的 SQL 内字段转换 CASE WHEN THEN ,
暂时还没有想好如何设计。如果是 SQL 原来的写法,则有点繁琐。
APIJSON 提供了各种安全机制,可在目前的基础上新增或改进。
目前有 RBAC 自动化权限管理。
APIJSONORM 提供 @MethodAccess 注解来配置
apijson-framework 则使用 Access 表 记录来配置
在 AbstractVerifier 中,假定真实、强制匹配。
目前有 预编译 + 白名单 校验机制。具体见 AbstractSQLExecutor 和 AbstractSQLConfig 。
目前有限流机制,getMaxQueryCount, getMaxUpdateCount, getMaxObjectCount, getMaxSQLCount, getMaxQueryDepth 等。
https://github.com/Tencent/APIJSON/blob/master/APIJSONORM/src/main/java/apijson/orm/Parser.java
优化 AbstractParser 和 AbstractObjectParser 解析 JSON 性能。
优化 AbstractSQLExecutor 封装 JSON 性能。
优化 AbstractSQLConfig 拼接 SQL 性能。
完善功能 中 Union 和 With 也是优化 SQL 性能的方式。
在 AbstractParser 使用了 HashMap<String, JSONObject> queryResultMap 存已解析的对象、总数等数据。
在 AbstractSQLExecutor 使用了 HashMap<String, JSONObject> cacheMap 存已通过 SQL 查出的结果集。
APIJSON 代码经过商业分析软件 源伞Pinpoint 的质检,报告说明 APIJSON 非常可靠。
Tencent#48
但我们需要再接再厉,尽可能做到 99.999% 可靠度,降低使用风险,让用户放心和安心。
APIAuto 上统计的 bug
账号 13000002000 密码 123456
http://apijson.org:8000/auto/
https://github.com/Tencent/APIJSON/issues?q=is%3Aissue+is%3Aopen+label%3Abug
https://gitee.com/TommyLemon/UnitAuto
https://github.com/Tencent/APIJSON/blob/master/Document.md
https://github.com/APIJSON/APIJSON-Demo/tree/master/APIJSON-Java-Server
Translation for Chinese document.
https://github.com/Tencent/APIJSON/blob/master/README-English.md
https://github.com/Tencent/APIJSON/blob/master/Document-English.md
https://github.com/ruoranw/APIJSONdocs
Go, Kotlin, Ruby 等。
https://github.com/APIJSON/APIJSON#%E7%94%9F%E6%80%81%E9%A1%B9%E7%9B%AE
JavaScript 前端,TypeScript 前端,微信等小程序,
Android 客户端,iOS 客户端,C# 游戏客户端等。
Java, C#, Node, Python 等后端 Demo 及数据。
https://github.com/APIJSON/APIJSON-Demo
1.基于或整合 APIJSONORM 或 apijson-framework 来实现的库/框架
2.扩展 APIJSONORM 或 apijson-framework 功能的插件
可以通过扩展对象关键词 @key,数组关键词 key,远程函数,重写部分方法等来实现。
因为 APIJSON 基于 JSON,大部分情况下都可以直接用 fastjson 等 JSON 封装/解析库或其它工具等,
只是 APIJSON 有部分功能需要在 key 里放 [], @ 等特殊符号,返回 [] 在某些情况下不方便解析,
目前可使用 "format": true 让后端格式化后返回,但也会对服务器性能有一些损耗,
如果 前端/客户端 有对应的格式化工具等(例如 apijson-orm 可供 Android 使用 format),选择就会更多一些。
https://github.com/Tencent/APIJSON#%E7%9B%B8%E5%85%B3%E6%8E%A8%E8%8D%90