https://github.com/jerrylususu/apijson_todo_demo/blob/master/FULLTEXT.md https://github.com/Tencent/APIJSON/wiki#%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86
-
建立数据库，创建apijson必须以来的几张表
- 执行apijson.sql文中的sql语句(apijson依赖表)
- 执行todo.sql（业务依赖表）
-
使用postman导入文件demo.postman_collection.json
-
运行程序，测试postman中的各个用例
- apijson orm本身就一个orm工具，更好的一点是不需要编码即可完成相关的upad
- 数据库链接相关配置在DemoSQLConfig中，如IP、Port、DataBase、user、password等信息
- CommonController 定义了对数据库表的通用增删改查操作，UserController定义了自定义的入口操作，和传统的spring mvc没有差异。
- 每个业务表的访问权限控制在Access表中，决定了CURD都对哪些角色开放，系统启动时读取该表写入内存 AbstractVerifier.ACCESS_MAP 中，执行时进行判决，数据变更需要重启服务。
- 每个请求基于tag进行检查设置，检查规则保存在Request表中，系统启动时读取该表写入内存 AbstractVerifier.REQUEST_MAP 中，执行时进行判决，数据变更需要重启服务。
- 对外公开的函数写入在表Function中， 系统启动时读取该表写入内存 AbstractFunctionParser.FUNCTION_MAP 中，执行时进行判决，数据变更需要重启服务。
-
创建apijson数据库及对应的系统表，初始化必要的数据；
-
创建业务表，并根据业务表的权限设置Access表数据
-
确定每个访问方法的request的规则，这个就是业务逻辑的体现
-
创建继承于APIJSONSQLConfig实体类，用于确定数据库访问方式；创建继承于APIJSONFunctionParser的实体类， 暴露对外的函数，并在Function中配置访问规则。 函数又可以在request中进行配置，作为业务处理签的校验：{"Todo": {"MUST": "id", "REFUSE": "userId", "UPDATE": {"checkCanPutx-()": "isUserCanPutTodo(id)"}}} 在对todo进行修改时，通过设置checkCanPutx-()，在业务处理前，先调用isUserCanPutTodo完成检查。
-
创建继承于APIJSONController的实体类，进行post到restful的转换。
-
model不是必须的，除非有json到model的转换，并进行业务的处理。如本demo中，Moment有表即可处理，不需要新建立一个Moment的Model来对应。
-
apijson本质上完成了json到sql的转换，通过灵活的语法来生成sql。难点是orm对应的sql生成器。
-
jdbc方式，演示了系统表和业务表必须在一个库中的场景
-
通过系统的三张表，控制了访问权限、请求格式校验、远程函数调用检验，这个思路还是不错的。
-
几个优化点：
-
通过注解实现这三张表，可以完全脱离数据库的使用。 通过三个注解（MethodAccess、RequestStructure、FunctionDef），动态完成对ACCESS_MAP、REQUEST_MAP、FUNCTION_MAP的填充； 全部使用注解，是可以完成所有动作的，比如本demo中的MomentComment类，通过添加MethodAccess和RequestStructure，使用扩展框架的如下代码，完成动态的规则设置： ApiJsonAnnotationUtil.fillAccessMap(MomentComment.class); ApiJsonAnnotationUtil.fillRequestMap(MomentComment.class);
-
函数强制绑定在一个APIJSONFunctionParser是不合适的，可以使用内存对象的方式搞定。
-
抽空了再实现一个FunctionDef注解，就可以废弃三张表了。
-