不用写代码 APIJSON 3.5K Star 超第 2 大 ORM 库 Hibernate

[TommyLemon]

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 的生态已初具雏形：

* 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

创作不易，GitHub 右上角点 ⭐Star 支持下吧，谢谢 ^_^

https://github.com/TommyLemon/APIJSON

[TommyLemon]

@kran 正是因为直接传 SQL 问题多，我才造轮子做出了 APIJSON。

SQL 不能直观地反映返回 JSON 的数据结构，
APIJSON 就能做到看请求知结果，所求即所得。

APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
还有 自动加注释、自动生成封装请求 JSON 的代码，用 SQL 方案实现也很困难，甚至根本不可能准确地实现。

至于业务逻辑，APIJSON 提供了 远程函数，后端写远程函数来实现，然后前端调用。
"isPraised()":"isContain(praiseUserIdList,userId)"
会调用 boolean isContain(JSONObject request, String array, String value) 函数，然后变为 "isPraised":true 这种（假设点赞用户 id 列表包含了 userId，即这个 User 点了赞）
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2

[TommyLemon]

@finian
这既是它的优势，也是它的问题所在。
不做具体实现，意味着可以对接各种服务，不限于 CRUD，
但带来的问题就是什么都要开发者自己手动实现 CRUD 等功能，
而且还得写一大堆 Schema，Type，resolver，
容易引发 N+1 查询问题，又得为每个需要优化的 Type 写几十行代码初始化及调用 DataLoader 来解决。

APIJSON 的确只限于做 CRUD，但 CRUD 在大部分互联网中小型项目中占了开发工作量的很大一部分，
APIJSON 帮助后端开发自动化解决了，不用写代码；前端还能很方便地定制数据和结构，不用催接口、求文档。

“ remote SQL 客户端” 可以这么理解，“完全面向 SQL ” 就不对了，APIJSON 提供了远程函数，请看 61 楼评论。


代码量才是导致 “可维护性差” 的最大原因，100 行代码能很好解决的事情，用 1000 行实现就 “可维护性差”，
APIJSON 的自动化 API 节省了大量的 CRUD 代码，反而是大幅提高了可维护性，甚至压根就不需要维护。


“业务数据层换成了 MongoDB 这种非关系型数据库”，是指先用关系型数据库，后换成非关系型数据库吧，
请问用什么系统不会“嗝屁”？别和我说仅仅通过改后端代码来兼容，这工作量和风险不是一般的项目能承受得起的。
能承受得起的，可能不用 APIJSON，用了 APIJSON 也可以直接改前端代码，后端还是很稳没啥要动的，
或者技术实力上来了直接重构，参考 GitHub，Twitter 等，都是一开始快速实现产品投放市场验证，
后面有钱、有人了想重构可以，想增强原有技术也行，例如 Facebook 魔改 PHP，Instagram 定制 Django。

如果一上来就是大项目，敏捷开发都未必适用了，这种我也不建议用 APIJSON。

[TommyLemon]

@zzzmode “写代码总是会和需求相结合”，这个明显也是说业务逻辑，APIJSON 提供了远程函数来实现业务，
请看 61 楼评论。

[TommyLemon]

@TommyLemon 这样既能节省大量的 CRUD 代码，又能在后端实现自己的业务逻辑，“通用性”就强了。

[TommyLemon]

@derrickT
确实是一直可以啊，只不过 SpringBoot 内嵌 Tomcat 这个 Web 容器，用来暴露 API，
不需要自己额外配一个了，虽然仍然可以是打包成 jar 包。

[TommyLemon]

@openthinks 刚刚大概看了下，没看懂核心原理，暂不评论，等有时间再仔细研究下

[TommyLemon]

@wfd0807 所以 APIJSON 提供了 自动化的权限控制，3 行代码就能配置各种角色对于一张表的增删改查权限。https://my.oschina.net/tommylemon/blog/889074

[TommyLemon]

@FrailLove
大致正确，其实是把“服务端”原来要大量手写的 API 抽象成了 APIJSON 的自动化 API，
前端通过它的协议来间接使用数据库的 CRUD 功能，当然后端也可以提供远程函数实现特定的业务逻辑，看 61 楼

[TommyLemon]

@hand515
群里已经有一些用户反馈用在 小程序、数据中心、可视化 等场景了，
还有个是在用 APIJSON 重构以前的项目（数据库用的是 PostgreSQL ），
我的建议是先不要动以前的 API,
新需求先用 APIJSON 实现，然后有时间再从简单的 API 开始用 APIJSON 替代，
原来的一些业务逻辑迁移到 远程函数，这样就能尽可能复用以前的代码。

[TommyLemon]

@sagaxu
APIJSON 自动化 API 能解决的，就不用写 CRUD 代码。

“如果后端自己去调用这个库，拼 json 真的比拼 sql/hql 简单吗？”
确实更简单，首先不管用什么方式开发 API，提供给前端的文档里是不能把后端代码贴上去代替 JSON 参数的，
反正都是要写，APIJSONAuto 自动化接口管理工具能根据左边的 JSON 自动生成在右边的封装它的代码，
复制粘贴到项目中改下值就能用，比起拼 SQL/HQL 就是要简单。
http://apijson.org/

[TommyLemon]

[TommyLemon]

@sagaxu 昨天回复数量达到上限了。

我说的一直都是“一定程度上”，当然你说的那几个指标确实也很重要。
如果 Star “毫无价值”的话，Hibernate 等一大堆开源库都未必会放到 GitHub 上了。
摘取知乎上两个评论：
“开源作者一不加薪二不升值，开源的驱动力本来就是成就感。”
“求 star 更多的获得认同和成就感 也会为作者带来些影响力和名气 如果这也批判的话 谁还做开源呀”

搜索结果的数量是少啊，APIJSON 这不才 2 年嘛，Hibernate 都快 12 年了才有现在的搜索量和热度啊。
从默默无闻到业内普及是有过程的，哪怕是大厂的开源项目也是如此，只不过会加速这个过程。
我想 Hibernate 刚开源时很可能也是有类似你这种评论，受到各种否定和质疑，但它还是发展起来了。

问题是那些就只能做 “简单的 CRUD ”，权限又怎么控制呢？还不是要写一堆代码。
而且它们是生成静态代码，会有很多不符合业务需求的代码要做二次开发，而且也基本只能在新需求用。
已经开发过的需求，如果再用新生成的代码覆盖肯定不行，往往因为业务逻辑也不能简单地替换已分散的代码，
找到能替换的部分在一段段替换，往往成本过高，还不如直接在原来的基础上改。

貌似真的只有 DSL 才能做到完全自动化了，后端不写代码就能自动化解析前端传的参数。
APIJSON 就是一种基于 JSON 扩展而来的 DSL，实现了前端动态传 JSON，后端动态解析为 SQL，
如果需求改了，前端把 JSON 参数改下，后端不用改接口或新增接口，
总之就是不用写代码，仍然自动解析为 SQL，满足新的需求。

APIJSON 能自动化实现的可不仅仅是“简单的 CRUD ”，还有复杂的查询，包括多表关联查询，自动化 join 等。
github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

[TommyLemon]

@wzw APIJSON Python 版，创作不易，给作者点 Star 支持下吧^_^
https://github.com/zhangchunlin/uliweb-apijson