@ksssdh123 目前还没看到所谓权威的对比，这个 issue 里有几个网友评价了
https://github.com/APIJSON/APIJSON/issues/2

@dk7952638 @tt67wq @ddup 感谢支持^_^
就像我一个前同事在 ofo 做运营，她和我说每投放一个城市的单车，都要先喂饱那些私占的人才有大量目标用户使用。
我这也是先被 各种角度、各种无脑、各种没依据、各种凭主观感受 喷过后，才终于有了一些理性客观的评论哈哈。

v2ex 上要等被喷得差不多了才会有理性的发言

@fghjghf Protobuff, Thrift, Dubbo 等 RPC 协议主要不是为了方便，而是为了传输性能而生的，
虽然能生成一些接口实现与调用的代码，但并没有像 HTTP API 那样有成熟完善文档工具，
所以一般更适合内部使用，尤其是微服务间互相调用，对于前后端分离的项目，联调反而更麻烦。

@kiinlam APIJSON 提供了自动化 JOIN （ LEFT, RIGHT, INNER 等 SQL JOIN 和 应用层连表 APP JOIN ）来优化性能
数组关键词
④ "join":"&/Table0/key0@,</Table1/key1@"
多表连接方式：
"<" - LEFT JOIN
">" - RIGHT JOIN
"&" - INNER JOIN
"|" - FULL JOIN
"!" - OUTTER JOIN
"@" - APP JOIN
其中 @ APP JOIN 为应用层连表，会从已查出的主表里取得所有副表 key@ 关联的主表内的 refKey 作为一个数组 refKeys: [value0, value1...]，然后把原来副表 count 次查询 key=$refKey 的 SQL 用 key IN($refKeys) 的方式合并为一条 SQL 来优化性能；
其它 JOIN 都是 SQL JOIN，具体功能和 MySQL,PostgreSQL 等数据库的 JOIN 一一对应，
"ViceTable":{ "key@:".../MainTable/refKey" }
会对应生成
MainTable ... JOIN ViceTable ON ViceTable.key=MainTable.refKey。

再强调一下 APIJSON 不生成任何静态代码，只生成动态的 SQL 语句，
前端改了 JSON 参数，后端就生成新的 SQL 语句， 满足新的需求，
不需要后端写任何代码来实现上面的说 模糊搜索、分组排序 等，
还有自动化 JOIN 也不需要后端写代码：
```js
{
"[]": {
"count": 10, // LIMIT 10
"join": "</User/id@", // Comment LEFT JOIN User
"Comment": {
"content~": "a", // content REGEXP 'a'
"@group": "momentId", //GROUP BY momentId
"@order": "date+" //ORDER BY date ASC
},
"User": {
"@column":"id,name", // SELECT id,name
"id@": "/Comment/userId" // ON User.id = Comment.userId
}
}
}
```
APIJSONLibrary 生成
```sql
SELECT `Comment`.*, `User`.`id`, `User`.`name` FROM `sys`.`Comment` AS `Comment` WHERE `Comment`.`content` REGEXP 'a'
LEFT JOIN (SELECT `id`, `name` FROM `sys`.`apijson_user`) AS `User` ON `User`.`id` = `Comment`.`userId`
GROUP BY `Comment`.`momentId` ORDER BY `Comment`.`date` ASC LIMIT 10 OFFSET 0
```

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

还有 字段限制(可选)、查询缓存、查询预判、性能分析、过载保护 等多方面的优化
https://github.com/APIJSON/APIJSON/issues/16

@stillyu 这种生成静态代码的工具很多了，但都有几个很大的缺陷：
1.只能生成基本的简单增删改查，有 复杂嵌套、JOIN，子查询 等就不行了。
2.很多时候不能满足需求，还得在生成的代码上改，才能满足 GROUP BY、count(*) 等需求。
3.接口改过后有了不少逻辑，需求改了，用新生成的接口去替换成本很高，还不如在旧接口上改。

APIJSON 是对每次请求动态生成 SQL，需求变了就改请求，调用后就会自动生成新的 SQL，
这样就不用改后端代码，大部分情况下总是能满足各种定制性的需求。
https://raw.githubusercontent.com/TommyLemon/StaticResources/master/APIJSON/Share/Process.png

@kiinlam 说的 “需求变化或后端擦屁股问题” 正是 GraphQL 和传统 RESTful 等方式的问题，
APIJSON 恰好能很好地解决，大部分情况下总是不改后端代码就能满足需求。

APIJSON 怎么做复杂请求？
https://www.zhihu.com/question/61648519

你们可以在 APIJSONAuto 自动化接口管理工具上试试，任意调整数据和结构，
只要 请求符合 APIJSON 的协议、数据库有对应的表和字段、有权限访问表和字段 就能自动化支持。
请求 JSON 最外层加 "@explain": true 就能查看每个对象内自动生成的 SQL。
http://apijson.org/

@mmdsun 对的，基本原理就是这样
https://github.com/APIJSON/APIJSON/issues/38

后端重写相关的方法即可，DemoSQLExecutor.onPutColumn 判断 table 和 column，把密码字段的值 改成 * 星号。


不需要管原来各个 API 的的各种判断逻辑哦，加上 7 个自动化 API，直接
return new DemoParser(RequestMethod.GET).parse(request)
即可，如果有统一的权限控制（ session/cookie/jwt 等），在调用前判断即可。

@Feedline APIJSON 的核心是基于 APIJSON 协议开发的后端 ORM 库 APIJSONORM，对数据库全自动 CRUD，
它只有 49 个 Java 类（ 4 个 package_info.java 可有可无就不算了），只依赖 fastjson 一个库，非常轻量。
https://github.com/APIJSON/APIJSON/tree/master/APIJSON-Java-Server

打包出来的 apijson-orm-3.5.7.jar 只有 254 KB，且它里面没有 fastjson 的源码，也就不会冲突，
在你自己的工程里用 Maven(pom.xml)/Gradle(build.gradle) 或直接 jar /工程 等方式依赖 fastjson 即可。
https://github.com/APIJSON/APIJSON/tree/master/APIJSON-Java-Server/APIJSONBoot/libs

@Feedline ORM 适用场景还是很广泛的，至于具体到你的项目，那就具体分析了，不适合的场景也不建议使用

@yun33133 唉，是啊，还有很多人自己没有判断力，也不去验证，人云亦云，被这帮人误导了

很多压根就没仔细看过 文档 /Demo/视频 /源码，凭主观感受胡乱评价，凭空歪曲事实。还有人身攻击的(可见素质之低)

@Huelse 感谢支持

@TommyLemon 这几个方面 APIJSON “完爆” GraphQL，不服来辩，show me your evidence

@ianva
@tt67wq
@MissThee
@lijingyu68
@deadEgg
@wangxiaoaer
APIJSON 在安全上做了大量的自动防护和优化。
自动校验权限、结构、内容，自动限流过载保护，
自动防 SQL 注入，自动防误删误改数据。
https://github.com/APIJSON/APIJSON/issues/14/

攻击 GraphQL 的手段可多了
max.book118.com/html/2018/0919/5102220134001314.shtm

欢迎大家也在 APIJSON 上试试，成功了给 APIJSON 发个 issue：
APIJSON 源码，项目环境，攻击方式 /源码

APIJSON 全方面对比开源社区影响力前 3 的明星公司 “ Facebook ” 开发的 GraphQL：
基础功能、权限控制、表关联查询
https://github.com/APIJSON/APIJSON/issues/63/

@likaka 麻烦把类似的轮子发出来对比下，不要空口无凭谢谢

@yinzhili 请问你说的是哪个工程的代码？
如果是 APIJSON-Java-Server，已经有人测试过，可靠度 99.85%
https://github.com/APIJSON/APIJSON/issues/48

至于代码风格，主观感受各不一样，我们可以对照下阿里的 P3C Java 规范哦
https://github.com/alibaba/p3c

@sxw11
Java 开发工程师用 Java 写的 ORM 库，你说是前端就是前端了？ 哪里说了后端只有 CRUD ？
APIJSON 通过自动化 API 实现 [大部分] CRUD 的业务需求，
但还有部分需要特殊处理数据或结构的地方做不了自动化，
所以 APIJSON 提供了 [远程函数]，后端可以在里面写代码自定义自己的业务逻辑。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2

还有一小部分
很复杂的查询(一般对应报表之类的需求，各种 JOIN 和子查询 嵌套、字符串拼接 等，SQL 写一屏以上)、
复杂的事务操作(操作多表，还可能中间 CRUD 出现两种以上，各种校验、多次读写、事务回滚、定制异常等)
等用 APIJSON 做就很吃力了甚至不能实现，建议还是用手写接口(包括 SQL)的方式来实现。
还有后端也不止 CRUD，还有各种
报表统计、数据分析、个性化推荐、服务监控、数据库运维(如果没有 DBA 的话)
等工作，这些也不是 APIJSON 的适用范围或者说应用场景。

@hlwjia “整天挂在嘴边”？
“技术改变世界，前后协同变革” 是我在公司内开分享会时的一个 Slogan，
最上面的图片是分享会的 PPT 主题页，还加了日期时间打印出了邀请函。
公司总经理还说标语很好，建议 “前后协同变革” 改为 “协同驱动变革”。