我稍微看了下项目，感觉整体是比较精简、干净的，没有过多的第三方依赖。
感觉整个设计上是把现在的后台开发中（在我理解，后台=数据访问+业务逻辑）的数据层访问做了统一抽象复用。那剩下的业务逻辑也只能有两个方向处理：
1、向前端（C端或B端）进行转移；
2、还是后台提供，对统一抽象的数据访问接口再进一步数据加工；

zuo.biao.apijson.server.RemoteFunction这个类提供了对java方法调用的支持，我认为是对 上述的第2中情况的支持。像 apijson.demo.server.DemoFunction#deleteChildComment，就做到了"删除评论的子评论"的支持。

不知道我的理解和作者的设计有没有出入，文档和代码上没看得太出作者对zuo.biao.apijson.server.RemoteFunction设计的初衷。

就是第 2 种哈。
一方面可以不用前端去做业务逻辑处理，后端写好给前端在调用 /get, /head 查询 自动化 API 直接使用：
例如 "isPraised()":"isContain(praiseUserIdList,userId)" ，会调用 boolean isContain(JSONObject request, String array, String value) 函数，然后变为 "isPraised":true 这种（假设点赞用户id列表包含了userId，即这个User点了赞）

另一方面可以在 Request 表配置校验规则时，强制使用后端写的远程函数来校验前端调用 /post, /put, /delete 增删改 自动化 API 时传的参数：
例如 "verifyURLList-()": "verifyURLList(pictureList)" ，会调用 Object verifyURLList(JSONObject request, String urlList) throws Exception 函数校验传过来的 pictureList 里面每项是否为 URL。
注：接口 /get, /head 一般是不需要调用校验参数的远程函数的，这里为了方便演示用了 /get

3.2 功能符 远程调用函数 有说明哦
"key()":"函数表达式"，函数表达式为 function(key0,key1...)，会调用后端对应的函数 function(JSONObject request, String key0, String key1...)，实现 参数校验、数值计算、数据同步、消息推送、字段拼接、结构变换 等特定的业务逻辑处理，可使用 - 和 + 表示优先级，解析 key-() > 解析当前对象 > 解析 key() > 解析子对象 > 解析 key+()

https://github.com/APIJSON/APIJSON/blob/master/Document.md#3.2

不管是从文档还是从git上面的运行代码，都没能看出具体是什么场景下使用？

1）参数校验：是校验什么参数？入参还是出参？是像这样的校验吗：账户新增和修改，新增时账号为必填项，而修改时账号不可修改？

2）数值计算、字段拼接、结构变换 ：如果数据是从库中来的，那那通用SQL函数应该可以满足大部分需求。如果是从入参和库中数据来，那可以在客户端进行处理。
其实这种非标准化的后台个性化方法（非项目提供），本身就是不稳定的因素，这和项目原本追求后台接口稳定是有冲突的。

3）数据同步、消息推送：这些功能我觉得是对项目原来设计功能的扩展，这些已经超出了ORM定义的范围。
如果支持这些功能，项目能不能提供标准化的接口，即调用入口，包括请求方法、入参、出差格式等，而具体的同步规则、推送规则，则由项目的使用者去实现。
我觉得可以采用消息推送的方式，只产生信息，而具体的信息消费有使用者去定义，这样也能支持多机部署。

我觉得像 “数值计算、字段拼接、结构变换” 这些功能项目能否进行抽象，提供统一的方法，或是一个新的项目，作为插件式使用，增强结果输出。

让使用者无需定义即可使用；
如果定义的功能不满足需求其他功能，可由新版本进行发布添加；
如果使用者觉得无需这些功能，则可以把这个增强jar去除依赖，可以达到依赖精简作用；
如果使用者想自行开发增强功能，则实现已定义的抽象接口就好；

有太多是特定业务需求，要写特定算法，没法通用的。
远程函数只是一种扩展，提供给后端开发者去自定义实现。

常用的一些需求确实也可以提供对应的远程函数，DemoFunction 里就有 isContain 这种。