本文试着用 5W1H 方式切入，试图快速建立自己对 apijson 的整体认知，所以这不是一趟快速入门的 demo 之旅，而是显得比较务虚的探索式知识体系整合过程。
持续更新中…
1、Why
后端。
后端实现一种万能查询，并能减少绝大部分重复的常规数据CRUD功能及数据拼装等开发过程，定义一套统一的规范让前端来学习掌握，以后后端除了维护好这个 DSL 的运行时，就只需要做好数据实体的定义及权限维护可以了。
这里的前端，不一定只是 Web 前端开发，而是包含了更广义的 Client 端开发的大前端开发人员，比如安卓客户端开发人员、甚至包含部分在平台上做小应用的后端开发人员。
前端是时候 Get 一门新技能了。
2、What
官方：
APIJSON 是一种专为 API 而生的 JSON 网络传输协议 以及 基于这套协议实现的 ORM 库。
据个人理解，它定义了一整套 DSL 作为 API Client 的查询语言（Query Language）的规范(Specification)，同时也是的一款对应的后端具体实现(Implementation for the Spec at server side)。
是的，这会让人想起 GraphQL，如果做一些对比工作的话，会发现他们在 Spec 还是有重叠的部分的。 当然，一般国产的都是精品，APIJSON 也不会例外，APIJSON 在功能、安全、性能、易用性、Java 版生态(继承 JSON 的相关生态) 等方面都会比 GraphQL 更实用易用。
因此，可以考虑为这种 QL 取个名字，比如 ApijsonQL、或者短一点 apiQL。我选 apiQL。
Client 应用使用 apiQL 查询语言来请求支持 apiQL 的服务。
apiQL 是基于 JSON 数据格式定义的一种 DSL，对于 Cleint 开发人员来说，语法学习成本极低。剩下的，主要是熟悉领域特定的部分。
请求：
{
"[]":{
"page":0,
"count":3,
"Moment":{},
"User":{
"id@":"/Moment/userId"
},
"Comment[]":{
"count":3,
"Comment":{
"momentId@":"[]/Moment/id"
}
}
}
}
响应：
{
"[]":[
{
"Moment":{
"id":235,
"content":"xxx",
...
},
"User":{
...
},
"Comment[]":[
...
]
},
{
"Moment":{
"id":301,
"content":"xxx",
...
},
"User":{
...
},
...
},
...
],
"code":200,
"msg":"success"
}
apijson 如官方所述作为一款 ORM，其实质是将原来传统开发模式中的三层架构中的数据持久化层直接开放给前端，即压缩了领域层和表现层（很薄，仅做可选的权限校验，但是可以通过重写方法来自定义权限），几乎是让前端的视线直接穿透到数据持久化层来进行他们的对接开发工作。
前端开发需要建立一种新习惯 – 主动进行数据查询和拼接，而非像以前那般，等待后端拼接好再给出来。当然，也可以延续传统的开发习惯，由后端人员整理接口格式和生成文档，再有前端去调用，可以无缝衔接；不同的是，后端开发人员并没有”开发”的过程，只有写文档的过程。
具体如何实践，可以按团队实际情况来做选择。
借鉴 Restful Api 中的 verbs 术语，实际请求时全用HTTP POST请求。
实际使用时，最好在前端封装一套对应的 QueryBuilder，得到更 OO-Style 的体验，而不是记忆一堆”方言”词汇， 如 apijson-builder。
3、Who/When/Where
非金融类场景；中小型前后端分离的项目，尤其是 初创项目、内部项目、低代码/零代码、小程序、BaaS、Serverless 等。
4、How
TODO
5、Other
Original: https://www.cnblogs.com/x3d/p/apijson-lowcode.html
Author: x3d
Title: apijson 初探
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/799716/
转载文章受原作者版权保护。转载请注明原作者出处！