2021SC@SDUSC
分析项目前首先就是了解APIJSON。
在其官方文档 APIJSON官方文档 中说到，APIJSON是一种零代码、热更新、全自动 ORM 库、后端接口和文档零代码，前端(客户端) 定制返回 JSON 的数据和结构的工具。
通过文档看一下APIJSON对比传统的方式的优点（以传统RESTFUL为例）：
| 开发流程 | 传统方式 | APIJSON |
|---|---|---|
| 接口传输 | 等后端编辑接口，然后更新文档，前端再按照文档编辑请求和解析代码 | 前端按照自己的需求编辑请求和解析代码。 没有接口，更不需要文档！前端再也不用和后端沟通接口或文档问题了！ |
| 兼容旧版 | 后端增加新接口，用v2表示第2版接口，然后更新文档 | 什么都不用做！ |
| 前端请求 | 传统方式 | APIJSON |
|---|---|---|
| 要求 | 前端按照文档在对应URL后面拼接键值对 | 前端按照自己的需求在固定URL后拼接JSON |
| URL | 不同的请求对应不同的URL，基本上有多少个不同的请求就得有多少个接口URL | 相同的操作方法(增删改查)都用同一个URL， 大部分请求都用7个通用接口URL的其中一个 |
| 键值对 | key=value | key:value |
| 结构 | 同一个URL内table_name只能有一个 base_url/get/table_name? key0=value0&key1=value1... | 同一个URL后TableName可传任意数量个 base_url/get/ { TableName0:{ key0:value0, key1:value1, ... }, TableName1:{ ... } ... } |
| 后端操作 | 传统方式 | APIJSON |
|---|---|---|
| 解析和返回 | 取出键值对，把键值对作为条件用预设的的方式去查询数据库，最后封装JSON并返回给前端 | 把Parser#parse方法的返回值返回给前端就行 |
| 返回JSON结构的设定方式 | 由后端设定，前端不能修改 | 由前端设定，后端不能修改 |
以上只列举了小部分APIJSON相比于传统方式的特点。
经过总结—APIJSON实现的特点功能如下：
对于前端
- 不用再向后端催接口、求文档
- 数据和结构完全定制，要啥有啥
- 看请求知结果，所求即所得
- 可一次获取任何数据、任何结构
- 能去除重复数据，节省流量提高速度
对于后端
- 提供通用接口，大部分 API 不用再写
- 自动生成文档，不用再编写和维护
- 自动校验权限、自动管理版本、自动防 SQL 注入
- 开放 API 无需划分版本，始终保持兼容
- 支持增删改查、复杂查询、跨库连表、远程函数等
以上就是本人首次对APIJSON的了解，经过小组间讨论我们决定进行划分工作，我们对整个APIJSON项目代码进行定量与定性分析以及项目的关键及核心代码分析后，对每个人进行了围绕代码量的分工，最后大家无异议，本次项目的代码分析开始正式进行。
