https://www.timqian.com/star-history/#TommyLemon/APIJSON&hibernate/hibernate-orm
众所周知，Hibernate 是 Java 的第 2 大开源 ORM 库，从 2007 年开源到现在已经有近 12 年的历史。廉颇老矣，尚能饭否？ 长江后浪推前浪，一代新库换旧库。
为什么 APIJSON 从 2016 年 11 月开源后短短 2 年就超过它了呢？
因为 APIJSON 是自动化的，后端不用写代码，就能自动解析前端传的 JSON 参数，自动转为 SQL 语句并连接数据库执行，然后返回对应的 JSON 结果，期间自动校验权限、数据、结构，自动防 SQL 注入。
对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度
对于后端
提供通用接口，大部分API不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防SQL注入
开放API无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等
多表关联查询、结构自由组合、多个测试账号、一键共享测试用例
自动生成封装请求JSON的Android与iOS代码、一键下载自动生成的JavaBean
自动保存请求记录、自动生成接口文档
一键自动接口回归测试，不需要写任何代码(注解、注释等全都不要)
APIJSON 3.1.0 更新内容:
新增支持Between key%；
POST操作默认为OWNER角色且自动添加userId;
正则表达式符号新增支持~，且支持*忽略大小写；
Java Demo新增删除动态下所有评论的远程函数;
等价条件 key:value 不允许 JSONArray 类型；
PUT 请求在没有 SET 语句时直接报错;
解决 key! 报错;
优化key:value不合法的提示;
优化join解析异常的路径提示;
优化设置tag的提示;
更新MySQL表。
目前 APIJSON 的生态已初具雏形：
APIJSON 接口工具: https://github.com/TommyLemon/APIJSONAuto
APIJSON -Java版: https://github.com/TommyLemon/APIJSON
APIJSON - C# 版: https://github.com/liaozb/APIJSON.NET
APIJSON - PHP版: https://github.com/orchie/apijson
APIJSON -Node版: https://github.com/TEsTsLA/apijson
码云项目主页（源码、文档、视频）
引用来自“Nils张”的评论
你有了解过GraphQL吗？做的也是这个事情引用来自“孤独的探索号”的评论
Facebook 出的 GraphQL，你拿出来对比只能说明你没有对 它 和 APIJSON 有足够的了解。在 CRUD 上 APIJSON 完爆 GraphQL：
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(一)-基础功能
juejin.im/post/5ae80edd51882567277433cf
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(二)-权限控制
juejin.im/post/5b13cda1f265da6e4a6bcfee
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(三)-表关联查询
juejin.im/entry/5b4ff88f6fb9a04f914a8df5
目前我已知的所有的开源库，只有 APIJSON 能做到 关系型数据库 自动化 CRUD，
如果有别的，欢迎告诉我，我会认真了解和对比下。
以下项目主页包括 源码、部署与协议文档、视频教程、接口工具等。
创作不易，GitHub 右上角点 ⭐Star 支持下吧，谢谢 ^_^
github.com/TommyLemon/APIJSON
引用来自“Nils张”的评论
自己搞一个这样的东西，我还是很佩服的，不过你说的那些完爆的点，我觉得不是GraphQL没做到，是它没去做，老外喜欢定标准，让大家根据实际需求来做实现并贡献。你的目标确实和它不一样，很落地，国外的框架很多拿过来是需要做一个公司有专家做二次调整来适配公司普通开发人员做开发的，你做的我认为是可以直接在项目中用的。
请多吸取大家的意见不断优化吧，加油
引用来自“苏显斌的博客”的评论
我看到大家有在讨论事务的问题，本人还没有用过，但是文档和部分代码简单看了一下，发表一下个人见解。目前的话，这个项目确实能解决不少问题，但是从构建软件系统的架构方面考虑，会有几个问题：
1、针对数据库的操作，必然多出多套实现方案，apijson一套、mybaties（或者hibernate）一套、jdbc一套，甚至还有其他的，基层的开发实施过程中，因为水平的关系，容易出问题；
2、缺乏事务之后，对系统设计带来不少困扰，首先是表设计，因为基本都ORM了，那么也就是Entity之间的关联性比较大，大部分都是一对多，多对多的关系，如果缺少事务，就无法保证数据完整性的问题，对系统建设是一个很大的隐患；
3、就目前的开发技术，比如SpringBoot+SpringDataJPA，实现一个REST API，已经非常的简单，代码量非常少，类似增删查改的基础操作，基本上不需要些太多代码，并且有完整的事务控制。
当然，apijson这样的设计理念，我觉得是未来的趋势（特别有利于微服务架构的API开发），我个人非常看好，只是软肋方面需要完善。个人觉得首要的还是考虑基于类似SpringDataJPA，或者Hibernate底层构建，加入事务的控制机制，这样基本上应用范围就非常广。
至于部分人在讨论代码量多少的问题，我觉得这个不是重点，apijson只是提供新的模式，系统根据规模，不一定都是三层架构；另外，apijson跟多是存在于数据层，所以进行系统设计的时候，可以考虑数据层基础操作使用apijson结合jpa等等，业务层来调用这一层，乍一看，是不是很像微服务？这就是了，以后系统规模的不断增大，系统开发成本的不断增加，是需要这样的解决方案的。
1.问题确实存在，但用不用得看成本和收益，
规模达到一定程度后别说几个同类开源库同时用，就连后端语言都很可能会有 Java，PHP, Node.js 搭配。
2.APIJSON 目前的确缺乏事务，所以也在文档中说明了自动化 API 的适用范围是 简单的增删改查、复杂的查询、简单的事务操作。
APIJSON 的 ORM 和 Hibernate 等其它 ORM 一个最大的区别就是，它的对象是用 JSON 而不是 POJO，
这样就允许前端传 JSON 参数过来定制接口返回 JSON 的数据和结构，而不是只能写死在后端不支持定制的 POJO。
用 APIJSON 自动化 API 去做复杂事务的确会存在这种隐患，
但这不是 APIJSON 的适用范围，也不提倡这么做，建议还手写接口，可控性强。
3.这种库有很多，我也看过 JPA 等，
它们是生成静态代码，会有很多不符合业务需求的代码要做二次开发，而且也基本只能在新需求用。
已经开发过的需求，如果再用新生成的代码覆盖肯定不行，往往因为业务逻辑也不能简单地替换已分散的代码，
找到能替换的部分在一段段替换，往往成本过高，还不如直接在原来的基础上改。
貌似真的只有 DSL 才能做到完全自动化了，后端不写代码就能自动化解析前端传的参数。
APIJSON 就是一种基于 JSON 扩展而来的 DSL，实现了前端动态传 JSON，后端动态解析为 SQL，
如果需求改了，前端把 JSON 参数改下，后端不用改接口或新增接口，
总之就是不用写代码，仍然自动解析为 SQL，满足新的需求。
微服务确实是 APIJSON 的一个应用场景，有个群友他的老项目比较庞大复杂，我建议他不要整合 APIJSON，
而是把 APIJSON 单独作为一个微服务，然后使用仅在内部能访问的端口暴露 API 给其它服务，
他最后就是这么做的，在到达 APIJSON 服务前用自己原项目做了自定义的鉴权，我印象中这是半年前的事了。
其实 APIJSON 目前最适合的是中小型前后端分离的项目，
尤其是互联网创业项目和企业自用项目，能大幅降低开发和沟通成本，简化开发流程。
最后，软件开发没有银弹，在适合的场景使用适合的工具才是最有效、利润(收益-成本)最高的方式。
引用来自“wangxinxx”的评论
第一大是什么？引用来自“TGVvbmFyZA”的评论
MyBatis？引用来自“孤独的探索号”的评论
确实是 MyBati，不过它要写大量的嵌套原生 SQL 的 XML 代码哦。APIJSON 完全不用，前端传 JSON 过来，后端全自动化解析为 SQL 语句执行并返回 JSON 结果，
期间自动校验权限、数据、结构，自动防 SQL 注入。
引用来自“orpherus”的评论
既然从前端传的json能自动构造出sql，这个json必须含有相当的信息量，本质上是用json做dsl描述sql做的事情。那不是消除了后端代码，只是把后端部分逻辑push到了前端。关于前端逻辑增加，这个是前端定制后端返回的数据内容和结构必然会带来的问题，
RESTful 接口要定制分页数量、页码、排序，不也得加 pageSize,pageNum, "param": { "orderBy":{ "date": "DESC" } }
等类似 Mybatis-PageHelper 里的字段，导致前端逻辑增加？
前端要定制得越多，就得传越多的信息，后端就得支持越多的定制需求，解析越多的参数，
用什么方式做都是这样，但 APIJSON 至少能保证后端不写代码，这又是其它开源库做不了的。
事物都是两面性的，不能“只享受利益不承担责任“， 软件开发没有银弹。
而且 APIJSON 提供了一套统一且简单清晰的规范以及丰富的示例：
[设计规范](https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3)
加上 APIJSON 提倡后端把 测试用例（请求的URL和JSON参数）填好上传到 APIJSONAuto 接口管理工具
http://apijson.org/
所以前端直接点一下就有了 URL 和 JSON 参数，复制过来就行了。
Android，iOS客户端可以复制右侧自动生成的代码。
用 APIJSON，请求代码就不是问题了。
引用来自“Nils张”的评论
你有了解过GraphQL吗？做的也是这个事情在 CRUD 上 APIJSON 完爆 GraphQL：
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(一)-基础功能
juejin.im/post/5ae80edd51882567277433cf
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(二)-权限控制
juejin.im/post/5b13cda1f265da6e4a6bcfee
完爆 Facebook/GraphQL，APIJSON 全方位对比解析(三)-表关联查询
juejin.im/entry/5b4ff88f6fb9a04f914a8df5
目前我已知的所有的开源库，只有 APIJSON 能做到 关系型数据库 自动化 CRUD，
如果有别的，欢迎告诉我，我会认真了解和对比下。
以下项目主页包括 源码、部署与协议文档、视频教程、接口工具等。
创作不易，GitHub 右上角点 ⭐Star 支持下吧，谢谢 ^_^
github.com/TommyLemon/APIJSON
引用来自“wangxinxx”的评论
第一大是什么？引用来自“TGVvbmFyZA”的评论
MyBatis？引用来自“孤独的探索号”的评论
确实是 MyBati，不过它要写大量的嵌套原生 SQL 的 XML 代码哦。APIJSON 完全不用，前端传 JSON 过来，后端全自动化解析为 SQL 语句执行并返回 JSON 结果，
期间自动校验权限、数据、结构，自动防 SQL 注入。
目前的话，这个项目确实能解决不少问题，但是从构建软件系统的架构方面考虑，会有几个问题：
1、针对数据库的操作，必然多出多套实现方案，apijson一套、mybaties（或者hibernate）一套、jdbc一套，甚至还有其他的，基层的开发实施过程中，因为水平的关系，容易出问题；
2、缺乏事务之后，对系统设计带来不少困扰，首先是表设计，因为基本都ORM了，那么也就是Entity之间的关联性比较大，大部分都是一对多，多对多的关系，如果缺少事务，就无法保证数据完整性的问题，对系统建设是一个很大的隐患；
3、就目前的开发技术，比如SpringBoot+SpringDataJPA，实现一个REST API，已经非常的简单，代码量非常少，类似增删查改的基础操作，基本上不需要些太多代码，并且有完整的事务控制。
当然，apijson这样的设计理念，我觉得是未来的趋势（特别有利于微服务架构的API开发），我个人非常看好，只是软肋方面需要完善。个人觉得首要的还是考虑基于类似SpringDataJPA，或者Hibernate底层构建，加入事务的控制机制，这样基本上应用范围就非常广。
至于部分人在讨论代码量多少的问题，我觉得这个不是重点，apijson只是提供新的模式，系统根据规模，不一定都是三层架构；另外，apijson跟多是存在于数据层，所以进行系统设计的时候，可以考虑数据层基础操作使用apijson结合jpa等等，业务层来调用这一层，乍一看，是不是很像微服务？这就是了，以后系统规模的不断增大，系统开发成本的不断增加，是需要这样的解决方案的。
https://www.oschina.net/news/109271/apijson-3-7-0-released
长久以来本人只是谨慎观望的态度，中国开源希望感觉越来越大了，希望这个项目随着发展壮大，希望能够加入部分商业化的东西，毕竟一个开源作者如果没有商业场景加入（收入来源），这个项目很难像Spring等等长久发展下去，毕竟热情的东西无法持久。比如LayUI，有免费和收费的东西，相互不影响。
第一种，挂靠一些创业公司，整合资源一起做；
第二种，注册一家个体户，个体户的名称可以使用某某软件工作室，个体户有正规营业执照，可以开普票和专票，并且最主要的是，个体户没有公司的要求，需要委托第三方报税，养个体户的成本几乎为零。
以上满足之后，你就可以做各类简单的业务了，毕竟个体户也有营业执照，也能开各类发票，签署合同。
剩下的，就看你自己业务怎么处理了，这个我没法帮。
引用来自“双城记”的评论
这玩意不会暴露数据库结构吗？难道你们的应用都是把数据库原始数据取出来然后直接给前端，不需要格式化封装处理？引用来自“孤独的探索号”的评论
会暴露，好处就是能不用写代码，直接自动查数据库生成文档http://apijson.org/
其实就算是用传统方式（Hibernate，Mybatis，甚至直接传SQL）, 大部分项目也不会怎么注意，
POJO 就是和表完全对应， 尤其是用 Hibernate 这种 ORM 库，AS 别名也只是全大写转为小驼峰，
加上 URL 的 base_url/users 这种和表名对应的后缀，不也暴露了嘛。
还有数据库执行出错后也会把 JDBC 驱动的错误信息作为 errMessage 返回，里面就有 SQL 片段，也暴露了。
单独拿 APIJSON 来说这个问题就是耍牛氓了，再说 APIJSON 提供表名映射，例如 User 对应的表其实是 apijson_user，
可以不暴露表名。
格式化处理有两个方面：
一个是结构，APIJSON 允许前端定制 JSON 结构，恰恰是很大的优势，
不用费脑子去解析后端拍脑袋随意定的 “能用就行”的结构，而是根据自己的需要拿到好用的结构。
另一个是字段转化，包括名称和值，这个 APIJSON 也提供了远程函数，前端调用后端扩展的函数即可。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2
引用来自“双城记”的评论
“还有数据库执行出错后也会把 JDBC 驱动的错误信息作为 errMessage 返回，里面就有 SQL 片段，也暴露了。”难道没有全局异常拦截吗？直接把异常栈暴露给前端用户？这也太蠢了吧。。？另外是不是类似user这种数据表，只要知道相关列名就可以password telephone address加进筛选列是不是就可以拿到各种用户敏感数据了？
对于复杂的业务逻辑还是需要另外写接口来实现自己的细节。如果需要自己写接口，那么url入参出参格式都肯定会和你这个框架格式有很大的不同，对于前端开发人员，一个系统有两种不同规范和风格设计风格要骂了。
所以我感觉这个东西只适合开发环境便捷的查询数据，不适合生产环境使用，实际上类似spring boot data已经有url自动映射数据库表数据的功能了。
另外你这个stars真不是刷出来的？同样3.5k stars数量，hibernate issuses有2600多个，而你这个好像才40多个？
引用来自“孤独的探索号”的评论
只要给够钱、人、设备等资源，几乎想得到的就能做到，然而真的存在不用控制成本的项目吗？你能指望一大堆中小型企业能有 FLAG， BAT 等大公司的资源？
也许你在的项目组没有这些问题，但我见过的项目，包括自己参与或主导的、圈子内的就有一大堆项目是这样。
时间是检验真理的唯一标准，瞎猜有什么用？
APIJSON 提供了自动化的权限控制、自动校验参数、自动防SQL注入、自动过滤字段。
前后端源码、文档、测试工具、视频教程 都提供了，你试试看嘛，成功了发个 issue。
你也说是“复杂的业务逻辑”嘛，APIJSON 自动化 API 能简单实现的就用，不能就自己写，有什么额外的损失吗? 反而是能用 APIJSON 简单实现的 API 省了一大堆。
如果后面需求变得很复杂，自动化 API 难搞定，那就再自己写呗。
所以只是你的“感觉”，群里一些用户反馈自己的公司项目用 APIJSON 实现，都上线超过半年了，非常稳定可靠。
spring boot data 没搜到，只看到名称类似的，麻烦给个准确的链接，谢谢。
看起来你对 issue 的理解不到位：
1.issue 是一个公开的讨论区，可以发任何东西。
2.大部分issue都是 提交bug、提建议、提问题（如何使用XXX，怎么添加XXX，有没有文档 等），还有些是灌水、发泄 等。
3.issue 的数量和 Repo 的 受关注程度、使用频率、Repo本身的代码与文档质量 等相关。
Hibernate 使用率是远高于 APIJSON 的，毕竟从 07 年开源到现在都快 12 年了，APIJSON 才 2 年多一点。
还有 Hibernate 都关掉 issue 板块了，现在看不了我暂且相信你说的 2600多个。
你可以说 issue 数量多反映使用率高，
我也可以认为 issue 数量相对少体现 bug 少及简单易用，
才没有大量的 issue 来提交 bug、咨询使用方法 /文档 等。
至于刷 Star，我从来没做过这种事，从法律上来说，谁主张谁举证。
你拿出 issue 这个说服力不够的依据，就来轻易造谣坏我的名声？
那我是不是可以根据你这些带有轻浮和嘲讽的评论，造谣你没做过的坏事？
本来我都懒得证明了，想想还有一些不了解的人可能被你随口说出来的话误导，我还是再用真实依据来说明下：
APIJSON 开源道现在2年左右时间，不断完善优化，多次发博客、发帖、评论等方式推广，才有了现在的 Star 数量。
看下 Star 趋势图，压根就没有像某库几天到 100 Star 后还成倍增长的片段（那种都是垂直竖线了）；
https://www.timqian.com/star-history/#TommyLemon/APIJSON
看下给 Star 的用户账号（货真价实，还有50个左右阿里、腾讯、百度的）
http://link.zhihu.com/?target=https%3A//haochuan9421.github.io/stargazers
看下Commit
https://github.com/TommyLemon/APIJSON/commits/master
看下Release
https://github.com/TommyLemon/APIJSON/releases
看下我的博客的阅读量、收藏量、粉丝数
https://my.oschina.net/tommylemon
https://www.cnblogs.com/tommylemon/
https://juejin.im/user/5900b2b1a22b9d0065bfaec6/posts
这些数据都会有部分转化为 Star。
要是都刷 Star了，还需要这么费劲地 写博客、发帖子、写评论、回复评论 等做这么多事吗？
引用来自“双城记”的评论
这玩意不会暴露数据库结构吗？难道你们的应用都是把数据库原始数据取出来然后直接给前端，不需要格式化封装处理？引用来自“孤独的探索号”的评论
会暴露，好处就是能不用写代码，直接自动查数据库生成文档http://apijson.org/
其实就算是用传统方式（Hibernate，Mybatis，甚至直接传SQL）, 大部分项目也不会怎么注意，
POJO 就是和表完全对应， 尤其是用 Hibernate 这种 ORM 库，AS 别名也只是全大写转为小驼峰，
加上 URL 的 base_url/users 这种和表名对应的后缀，不也暴露了嘛。
还有数据库执行出错后也会把 JDBC 驱动的错误信息作为 errMessage 返回，里面就有 SQL 片段，也暴露了。
单独拿 APIJSON 来说这个问题就是耍牛氓了，再说 APIJSON 提供表名映射，例如 User 对应的表其实是 apijson_user，
可以不暴露表名。
格式化处理有两个方面：
一个是结构，APIJSON 允许前端定制 JSON 结构，恰恰是很大的优势，
不用费脑子去解析后端拍脑袋随意定的 “能用就行”的结构，而是根据自己的需要拿到好用的结构。
另一个是字段转化，包括名称和值，这个 APIJSON 也提供了远程函数，前端调用后端扩展的函数即可。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2
引用来自“双城记”的评论
“还有数据库执行出错后也会把 JDBC 驱动的错误信息作为 errMessage 返回，里面就有 SQL 片段，也暴露了。”难道没有全局异常拦截吗？直接把异常栈暴露给前端用户？这也太蠢了吧。。？另外是不是类似user这种数据表，只要知道相关列名就可以password telephone address加进筛选列是不是就可以拿到各种用户敏感数据了？
对于复杂的业务逻辑还是需要另外写接口来实现自己的细节。如果需要自己写接口，那么url入参出参格式都肯定会和你这个框架格式有很大的不同，对于前端开发人员，一个系统有两种不同规范和风格设计风格要骂了。
所以我感觉这个东西只适合开发环境便捷的查询数据，不适合生产环境使用，实际上类似spring boot data已经有url自动映射数据库表数据的功能了。
另外你这个stars真不是刷出来的？同样3.5k stars数量，hibernate issuses有2600多个，而你这个好像才40多个？
你能指望一大堆中小型企业能有 FLAG， BAT 等大公司的资源？
也许你在的项目组没有这些问题，但我见过的项目，包括自己参与或主导的、圈子内的就有一大堆项目是这样。
时间是检验真理的唯一标准，瞎猜有什么用？
APIJSON 提供了自动化的权限控制、自动校验参数、自动防SQL注入、自动过滤字段。
前后端源码、文档、测试工具、视频教程 都提供了，你试试看嘛，成功了发个 issue。
你也说是“复杂的业务逻辑”嘛，APIJSON 自动化 API 能简单实现的就用，不能就自己写，有什么额外的损失吗? 反而是能用 APIJSON 简单实现的 API 省了一大堆。
如果后面需求变得很复杂，自动化 API 难搞定，那就再自己写呗。
所以只是你的“感觉”，群里一些用户反馈自己的公司项目用 APIJSON 实现，都上线超过半年了，非常稳定可靠。
spring boot data 没搜到，只看到名称类似的，麻烦给个准确的链接，谢谢。
看起来你对 issue 的理解不到位：
1.issue 是一个公开的讨论区，可以发任何东西。
2.大部分issue都是 提交bug、提建议、提问题（如何使用XXX，怎么添加XXX，有没有文档 等），还有些是灌水、发泄 等。
3.issue 的数量和 Repo 的 受关注程度、使用频率、Repo本身的代码与文档质量 等相关。
Hibernate 使用率是远高于 APIJSON 的，毕竟从 07 年开源到现在都快 12 年了，APIJSON 才 2 年多一点。
还有 Hibernate 都关掉 issue 板块了，现在看不了我暂且相信你说的 2600多个。
你可以说 issue 数量多反映使用率高，
我也可以认为 issue 数量相对少体现 bug 少及简单易用，
才没有大量的 issue 来提交 bug、咨询使用方法 /文档 等。
至于刷 Star，我从来没做过这种事，从法律上来说，谁主张谁举证。
你拿出 issue 这个说服力不够的依据，就来轻易造谣坏我的名声？
那我是不是可以根据你这些带有轻浮和嘲讽的评论，造谣你没做过的坏事？
引用来自“双城记”的评论
看了一下lz的博客，感觉lz就是自己想越过职责范围想去完成后端的事，所以搞出了这么个东西。然而实际上后端并不是你想的那样只是增删改查的事。
不然 APIJSON 就不会有这么多 Star，甚至还超过了 Hibernate。
我从来没认为后端只是增删改查，后端还有 服务监控、微服务、数据分析、个性化推荐 ...
但大部分项目中 增删改查（CRUD）就是占据了需求的大部分，
而能用 APIJSON 的自动化 API 解决的又占了这里面的大部分，
能够帮助后端自动化地完成大部分 CRUD 的需求、同时又让前端能很方便地实现自己的需求，
这有什么不好呢？非得前后端天天扯皮，进度一直拖着？
为什么要用APIJSON？前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki
引用来自“双城记”的评论
另外对于web/客户端一些接口，需要一些状态码，不同状态下的展示不同的数据。所以类似提交订单前，订单是否缺货，是否符合购买条件，是否满足满减优惠这些业务统统都要前端自己另外调用接口判断？
这样可是非常的不靠谱，事务并发控制全部都无法保证。
如果你所谓的优势只是为了少些一点代码，那还真是不是什么优势。还不如前端直接传sql语句，后段解析sql语句做字段映射/鉴权。敲一句sql总比你拼一个json字符串方便吧？
APIJSON是一种为API而生的JSON网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的API。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。
直接传 SQL， 解析SQL语法，再校验权限、结构、内容，最后再转回SQL，
不说性能问题，真要这么好搞业内也应该有不错的开源方案了。
而且SQL不能直观地反映返回JSON的数据结构，
APIJSON就能做到看请求知结果，所求即所得。
APIJSON的 提取字段、远程函数 功能也不是SQL方案能方便地实现的。
还有 自动加注释、自动生成封装请求JSON的代码，用SQL方案实现也很困难，甚至根本不可能准确地实现。
为什么要用APIJSON？前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki
然而实际上后端并不是你想的那样只是增删改查的事。
引用来自“巴林的狗尾草”的评论
意思是以后的业务逻辑判断，第三方调用验证啥的都放到C端做了？感觉意义不大引用来自“双城记”的评论
感觉也就开发测试阶段方便查一下数据。把业务逻辑移到c端，想都不敢想象。。。
引用来自“巴林的狗尾草”的评论
意思是以后的业务逻辑判断，第三方调用验证啥的都放到C端做了？感觉意义不大把业务逻辑移到c端，想都不敢想象。。。
所以类似提交订单前，订单是否缺货，是否符合购买条件，是否满足满减优惠这些业务统统都要前端自己另外调用接口判断？
这样可是非常的不靠谱，事务并发控制全部都无法保证。
如果你所谓的优势只是为了少些一点代码，那还真是不是什么优势。还不如前端直接传sql语句，后段解析sql语句做字段映射/鉴权。敲一句sql总比你拼一个json字符串方便吧？
引用来自“双城记”的评论
这玩意不会暴露数据库结构吗？难道你们的应用都是把数据库原始数据取出来然后直接给前端，不需要格式化封装处理？http://apijson.org/
其实就算是用传统方式（Hibernate，Mybatis，甚至直接传SQL）, 大部分项目也不会怎么注意，
POJO 就是和表完全对应， 尤其是用 Hibernate 这种 ORM 库，AS 别名也只是全大写转为小驼峰，
加上 URL 的 base_url/users 这种和表名对应的后缀，不也暴露了嘛。
还有数据库执行出错后也会把 JDBC 驱动的错误信息作为 errMessage 返回，里面就有 SQL 片段，也暴露了。
单独拿 APIJSON 来说这个问题就是耍牛氓了，再说 APIJSON 提供表名映射，例如 User 对应的表其实是 apijson_user，
可以不暴露表名。
格式化处理有两个方面：
一个是结构，APIJSON 允许前端定制 JSON 结构，恰恰是很大的优势，
不用费脑子去解析后端拍脑袋随意定的 “能用就行”的结构，而是根据自己的需要拿到好用的结构。
另一个是字段转化，包括名称和值，这个 APIJSON 也提供了远程函数，前端调用后端扩展的函数即可。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2
引用来自“亚林瓜子”的评论
我家领导也是这个观点。我沉默了引用来自“孤独的探索号”的评论
什么观点？引用来自“亚林瓜子”的评论
业务逻辑前移引用来自“孤独的探索号”的评论
支持远程函数，后端提供远程函数来处理业务逻辑，前端调用就行了。引用来自“亚林瓜子”的评论
我家领导也是这个观点。我沉默了引用来自“孤独的探索号”的评论
什么观点？引用来自“亚林瓜子”的评论
业务逻辑前移引用来自“亚林瓜子”的评论
我家领导也是这个观点。我沉默了引用来自“孤独的探索号”的评论
什么观点？引用来自“亚林瓜子”的评论
我家领导也是这个观点。我沉默了引用来自“巴林的狗尾草”的评论
意思是以后的业务逻辑判断，第三方调用验证啥的都放到C端做了？感觉意义不大第三方验证自己在 APIJSON 前自己处理，或者也用远程函数。
引用来自“kidfruit”的评论
支持数据库的特殊用法么？比如oracle或者sqlserver有些自己的语法，必须sql语句，你这个怎么支持？引用来自“依山慕雪”的评论
GraphQL无法克说https://juejin.im/post/5ae80edd51882567277433cf
完爆Facebook/GraphQL，APIJSON全方位对比解析(二)-权限控制
https://juejin.im/post/5b13cda1f265da6e4a6bcfee
完爆Facebook/GraphQL，APIJSON全方位对比解析(三)-表关联查询
https://juejin.im/entry/5b4ff88f6fb9a04f914a8df5
引用来自“Tom-Lin”的评论
很棒。我原来也是想用 json 来代替 接口的，你实现了！引用来自“wangxinxx”的评论
第一大是什么？引用来自“TGVvbmFyZA”的评论
MyBatis？引用来自“孤独的探索号”的评论
确实是 MyBati，不过它要写大量的嵌套原生 SQL 的 XML 代码哦。APIJSON 完全不用，前端传 JSON 过来，后端全自动化解析为 SQL 语句执行并返回 JSON 结果，
期间自动校验权限、数据、结构，自动防 SQL 注入。
引用来自“TGVvbmFyZA”的评论
在和Spring結合的時候可以用註解寫SQL```js
{
"User": {
"id": 82001
}
}
```
自动转为
```sql
SELECT * FROM `User` WHERE `id`='82001' LIMIT 1 OFFSET 0
```
```js
{
"[]": {
"count": 10,
"page": 1,
"join": "</User/id@",
"Comment": {},
"User": {
"id@": "/Comment/userId"
}
}
}
```
自动转为
```sql
SELECT * FROM `Comment` LEFT JOIN `User` ON `User`.`id` = `Comment`.`userId` LIMIT 10 OFFSET 10
```
可以在 APIJSONAuto自动化接口管理平台测试
http://apijson.org/
引用来自“wangxinxx”的评论
第一大是什么？引用来自“TGVvbmFyZA”的评论
MyBatis？引用来自“孤独的探索号”的评论
确实是 MyBati，不过它要写大量的嵌套原生 SQL 的 XML 代码哦。APIJSON 完全不用，前端传 JSON 过来，后端全自动化解析为 SQL 语句执行并返回 JSON 结果，
期间自动校验权限、数据、结构，自动防 SQL 注入。
引用来自“wangxinxx”的评论
第一大是什么？引用来自“TGVvbmFyZA”的评论
MyBatis？APIJSON 完全不用，前端传 JSON 过来，后端全自动化解析为 SQL 语句执行并返回 JSON 结果，
期间自动校验权限、数据、结构，自动防 SQL 注入。