技术改变世界,前后协同变革 自动化 ORM 可靠度高达 99.85%

[TommyLemon]

APIJSON 3.5.0-3.5.7 更新内容:

• 新增存储过程 @key():"fun(...)"，用法基本和远程函数 key():"fun(...)" 一样；

• 新增性能分析 @explain 和缓存设置 @cache 两个对象关键词；

• 新增最大 对象数量、数组数量、嵌套层级等方法，限制请求、过载保护；

• 新增 PgClass 和 PgAttribute 查 PostgreSQL 的表属性和字段属性;

• LEFT JOIN 和 RIGHT JOIN 支持定制子查询外层的 column,group,order,having ；

• 多方面提升性能；完善和解决 bug 等；代码、文档等其它优化。

具体见 Release 发布版本。

APIJSON 简介

APIJSON 是一种为 API 而生的 JSON 网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的 API。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。

多表关联查询、结构自由组合、多个测试账号、一键共享测试用例

自动生成封装请求 JSON 的 Android 与 iOS 代码、一键下载自动生成的 JavaBean

自动保存请求记录、自动生成接口文档，可添加常用请求、快捷查看一键恢复

一键自动接口回归测试，不需要写任何代码(注解、注释等全都不要)

第三方机构对 APIJSON 的代码扫描，测试结果可靠性高达 99.85%

APIJSON 用 SpringBoot 提供了自动化 API，

自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，

期间自动校验权限、结构、内容，自动防 SQL 注入，

提供自动化的各种 JOIN(INNER, LEFT, RIGHT 等)，

还支持多字段排序 order by，多字段分组 group by，聚合函数 having

等几乎所有 MySQL,PostgreSQL,Oracle 的常规功能。

通过自动化 API，前端可以定制任何数据、任何结构！

大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！

前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！

后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析

• 自动生成接口文档，清晰可读永远最新

• 自动校验与格式化，支持高亮和收展

• 自动生成各种语言代码，一键下载

• 自动管理与测试接口用例，一键共享

• 自动给请求 JSON 加注释，一键切换

对于前端

• 不用再向后端催接口、求文档

• 数据和结构完全定制，要啥有啥

• 看请求知结果，所求即所得

• 可一次获取任何数据、任何结构

• 能去除重复数据，节省流量提高速度

对于后端

• 提供通用接口，大部分 API 不用再写

• 自动生成文档，不用再编写和维护

• 自动校验权限、自动管理版本、自动防 SQL 注入

• 开放 API 无需划分版本，始终保持兼容

• 支持增删改查、模糊搜索、正则匹配、远程函数等

🏆码云最有价值开源项目 🚀后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！

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

https://github.com/APIJSON/APIJSON

[TommyLemon]

总共 10617 行代码，16 个「可能」的 bug，24 个改进建议， (1 - bugs/lines) 高达 99.85% 。
可见 APIJSON 代码非常严谨可靠。

[sleshep632]

第一次见到把“奖状”放到项目主页的...
如果按照这个项目逻辑，前端维护 db 索引吗？

[TommyLemon]

@sleshep632 放奖状有啥奇怪的，你去看看 Mybatis-Plus，
再说大部分项目都没有呢，GVP 又不是随便能申请到的。
建表、维护表那都是后端做的事，DB 索引当然也是后端维护，
源码、Demo、文档、视频都提供了，麻烦了解清楚再说，谢谢

[TommyLemon]

@TommyLemon https://gitee.com/baomidou/mybatis-plus

[MissThee]

之前看过 GraphQL 也是有点儿类似吧，都是前端给一些对象信息，后端根据这些信息组返回值。
暂时还不太喜欢这样的设计，感觉像是让前端写变体的 sql 查询语句一样。
总感觉这种方式怪怪的。想极端点儿，后台直接写一个接口接收原生 sql 语句，返回执行结果，前端学会原生 sql 语句，就可以解放后台了。。。-_-

[TommyLemon]

@MissThee 是有些类似，很多人没搞清楚总是说“比你的 APIJSON 强”，“完爆 APIJSON ”之类的。
事实上 Facebook 的 GraphQL 是 Gateway，而 APIJSON 是 ORM，有着本质上的区别，
真要放一般的互联网项目开发中拿来对比，那就是 APIJSON “完爆” GraphQL 了。
https://juejin.im/post/5ae80edd51882567277433cf

[TommyLemon]

@MissThee 我很早也考虑过直接传 SQL，而不是搞一个 APIJSON 的轮子。
但解析 SQL 语法，再校验权限、结构、内容，最后再转回 SQL，
不说性能问题，真要这么好搞业内也应该有不错的开源方案了。

而且 SQL 不能直观地反映返回 JSON 的数据结构，
APIJSON 就能做到看请求知结果，所求即所得。
APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
还有 自动加注释、自动生成封装请求 JSON 的代码，用 SQL 方案实现也很困难，甚至根本不可能准确地实现。

为什么要用 APIJSON ？或者 APIJSON 有什么用？
https://github.com/TommyLemon/APIJSON/wiki

[blless]

你又来辣…

每次看你刷屏都挺累的，这次说点正经的。虽然看起来确实挺有用，不过我肯定不会用的。
业务核心在于业务抽象跟业务建模。也就是设计业务的时候压根不会考虑接口层如何实现和数据层如何实现。核心业务实现完成后根据需求动态添加接口跟适配数据库。
小项目用用无所谓，大型项目用这种设计必然耦合越来越重，一个业务变更就是死

[anyele]

老哥我来辣

[TommyLemon]

@blless
APIJSON 可以用来大幅降低后端的开发工作量，大部分增删改查都不用写代码，前端直接调用自动化 API。
还可以解决前后端各种扯皮问题，简化开发流程，缩短开发周期。


RESTful，RPC 就不耦合了吗？还不是得适配前端的 UI，前端要微信朋友圈动态这种数据：
```js
{
"list": [
{
"Moment": {
"id": 12,
"userId": 70793,
"date": "2017-02-08 16:06:11.0",
"content": "APIJSON,let interfaces and documents go to hell !",
"praiseUserIdList": [
70793,
93793,
82044
],
"pictureList": [
"http://static.oschina.net/uploads/img/201604/22172508_eGDi.jpg",
"http://static.oschina.net/uploads/img/201604/22172507_rrZ5.jpg"
]
},
"User": {
"id": 70793,
"name": "Strong",
"head": "http://static.oschina.net/uploads/user/585/1170143_50.jpg?t=1390226446000"
},
"comemntList": [
{
"id": 162,
"toId": 0,
"userId": 93793,
"momentId": 12,
"date": "2017-03-06 13:03:45.0",
"content": "This is a Content...-162"
},
{
"id": 164,
"toId": 0,
"userId": 93793,
"momentId": 12,
"date": "2017-03-06 13:03:45.0",
"content": "This is a Content...-164"
}
]
},
{
"Moment": {
"id": 15,
"userId": 70793,
"date": "2017-02-08 16:06:11.0",
"content": "APIJSON is a JSON Transmission Structure Protocol …",
"praiseUserIdList": [
82002,
70793,
38710,
93793
],
"pictureList": [
"http://static.oschina.net/uploads/user/1218/2437072_100.jpg?t=1461076033000",
"http://common.cnblogs.com/images/icon_weibo_24.png"
]
},
"User": {
"id": 70793,
"name": "Strong",
"head": "http://static.oschina.net/uploads/user/585/1170143_50.jpg?t=1390226446000"
},
"comemntList": [
{
"id": 176,
"toId": 166,
"userId": 38710,
"momentId": 15,
"date": "2017-03-25 20:28:03.0",
"content": "thank you"
},
{
"id": 1490863469638,
"toId": 0,
"userId": 82002,
"momentId": 15,
"date": "2017-03-30 16:44:29.0",
"content": "Just do it"
}
]
}
],
"code": 200,
"msg": "success"
}
```
你提供多个接口：
一个查 Moment 列表，
一个根据 Moment.userId 查 User，
一个根据 Moment.id 查 Comment 列表，
让人家写出回调地狱的代码，嵌套调用，然后写算法把多个接口的数据整合起来？
期间多次的 HTTP 连接，多余的共同数据（ code,msg 等外层结构）不是浪费性能和流量？
如果只提供一个，那还不是耦合 UI 了? 前端 UI 一改，例如加上所有点赞的用户列表，
或者评论从单层变为要多层嵌套有上下级关系的，那接口也得跟着改，或者提供新的接口。

APIJSON 起码还能做到后端不用修改或新增接口，前端改下请求 JSON 就能拿到对应新 UI 的数据。


任何一个技术都有适用场景。

APIJSON 是一种为 API 而生的 JSON 网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的 API。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。

已经把适用场景说清楚了。

[TommyLemon]

@anyele 你好，请多多指教

[broadliyn]

我觉得 lz 的逻辑特别的搞笑。

可靠率是照 bug 行数来算的：“总共 10617 行代码，16 个「可能」的 bug，24 个改进建议， (1 - bugs/lines) 高达 99.85% 。可见 APIJSON 代码非常严谨可靠。”

普及率不用实际案例来说明，用的是 github 星星比 hibernate 多。

一个前端弄的后端框架好不好我不知道，就看楼主这秒天灭地的语气，表示非常想 diss+屏蔽。

另外放个码云的奖状真是 6 的不行。码云这种榜单前排项目清一色是 spring boot 权限集成管理手脚架的业余平台完全看不出这种奖状有什么价值。玻璃框+打印纸大概成本也就几十块钱吧。

可能楼主就是开源界的罗永浩吧。

[otakustay]

千行 BUG 率约 1.5，不算什么特别严谨可靠吧……

[allenhu]

数据的读写从来不是问题，问题是如果有些字段不允许读，或者读出来后需要经过处理再展示，要怎么做？

[royzxq]

issues 10 open 69 closed.
stars 5900.

issue 都通过 QQ 群解决了？

[rrfeng]

智障项目

[blless]

@TommyLemon restful rpc 只是协议，耦不耦合看业务设计，API 设计原则上也是要精确避免歧义跟最小数据…
你这套是数据流从前端直接穿透到后端数据库，耦合程度简直爆炸。而且原本业务开发核心其实是业务模型，到你这核心就变成数据库模型。
多说无益，反正你这项目我不看好。

[faceair]

这写法也挺酷的

[Eleutherios]

作为甲方，我不能接受这个东西。

如果是“自动生成后端程序代码和说明文档”的话，我会觉得还不错，但像这种“完全托管后端”的自动化程序……我不会信任。

[ziyue002]

作者的开源精神应该支持，但是还是想说，不看好~