APIJSON 3.2.0 发布, 4K Star 与 Hibernate 拉开差距

2018-12-20 10:17:38 +08:00
 TommyLemon

https://www.timqian.com/star-history/#TommyLemon/APIJSON&hibernate/hibernate-orm

APIJSON 3.1.1-3.2.0 更新内容:

对于前端

对于后端


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


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


自动保存请求记录、自动生成接口文档


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

APIJSON 生态内项目:

新鲜出炉的 Python 版  APIJSON 除了基本的查询(分页、排序等),还实现了自动化的权限控制。

给热心的作者们点 Star 支持下吧 ^_^

项目主页(源码、文档、视频、生态 等)

https://github.com/TommyLemon/APIJSON

10113 次点击
所在节点    程序员
76 条回复
pryhub
2018-12-20 13:20:00 +08:00
@TommyLemon #14 "数据库表字段配置的由数据库校验"
只由数据库校验?我理解的校验顺序是:1.前台要校验 2.后台逻辑代码校验 3.db 校验
TommyLemon
2018-12-20 15:04:43 +08:00
@pryhub 你理解的校验顺序很对,基本上都是这么一个流程。
"数据库表字段“ 配置的由 ”数据库校验",这句话也没错啊,就是第 3 个 db 校验。
前台校验是为了减少不必要的请求,后台逻辑代码校验是业务上的校验,可以自定义一些异常信息等。
lihongjie0209
2018-12-20 15:27:56 +08:00
比 start 没有意义
Kaiv2
2018-12-20 16:09:43 +08:00
怎么没看明白。。。啥意思?
jingyulong
2018-12-20 16:34:04 +08:00
文档看了半天没有发现如何使用。。。
liyuanba
2018-12-20 16:45:04 +08:00
我怎么觉得和 swagger 挺像的,都是做 API 管理的,我感觉 swagger 挺好用的啊,搭起来也方便。能做这么大一个 open source 的 repo,lz 牛逼。
TommyLemon
2018-12-20 16:45:06 +08:00
@lihongjie0209 Star 在一定程度上反映了 Repo 在开源社区的受欢迎程度,同类型的 Repo ( APIJSON 和 Hibernate 都是 ORM 库)对比是有参考意义的
TommyLemon
2018-12-20 16:46:40 +08:00
@jingyulong
如果是前端使用,直接用这个网站,还可以看通用文档或视频教程(网站顶部有链接)
http://apijson.org/

如果是后端部署,看这个部署文档
https://github.com/TommyLemon/APIJSON/tree/master/APIJSON-Java-Server
TommyLemon
2018-12-20 16:48:39 +08:00
@liyuanba
和 Swagger 像的是 APIJSONAuto 哈,这是一个接口管理工具。
https://github.com/TommyLemon/APIJSON/issues/27

APIJSON 主项目包括 协议、Java 版 ORM 库及 Demo,Android, iOS, JavaScript 的 Demo 等
liuhuansir
2018-12-20 16:52:13 +08:00
以前还会迷信 star 数,现在我更看重 issue 数量,数量多,修复快,说明用的人多
TommyLemon
2018-12-20 16:59:08 +08:00
@liuhuansir
Hibernate 的 issue 多到官方都关闭 issue 了,现在没法看。
https://github.com/hibernate/hibernate-orm

issue 的确反映了用户的数量及频率,但太多了也可能是 bug 太多,
issue/star <= 10% 是可接受的,> 20% 我一般找别的同类库了,找不到合适的可能基于现有的定制或干脆自己写。

关于 GitHub 的 issue
1.issue 是一个公开的讨论区,可以发任何东西。
2.大部分 issue 都是 提交 bug、提建议、提问题(如何使用 XXX,怎么添加 XXX,有没有文档 等),还有些是灌水、发泄 等。
3.issue 的数量和 Repo 的 受关注程度、使用频率、用户群体、Repo 本身的代码与文档质量 等相关。

APIJSON 提供了自动化 API,只有配置权限需要写极少的代码,加上详细的文档、视频教程、测试工具,
已经做到非常简单易用了,所以很少有问“怎样配置 XXX ”,“如何部署 XXX ”之类的问题。

APIJSON 经过 2 年时间维护、1000+次 Commit、40+ 次 Release, 功能上已经很完善、稳定,
所以也很少有用户问“如何解决 XXX ”之类的问题。

还有 APIJSON 目前大部分用户都是 国内的开发者,他们更倾向于在首页提供的 QQ 群交流和讨论。

https://github.com/TommyLemon/APIJSON/issues/53
loading
2018-12-20 18:24:24 +08:00
好像很厉害的样子,看看。
TommyLemon
2018-12-20 18:33:01 +08:00
@loading 哈哈,试试发现可能比想象的还好用
https://github.com/TommyLemon/APIJSON/issues/17
xiangyuecn
2018-12-20 19:23:01 +08:00
粗略的看了一下文档,虽然没看懂但是还是有个疑问:数据都是由前端自由组合来获取的,目测是比较粗粒度权限控制,那么会不会存在 C 端任意构造访问参数获取到本应授权访问的数据?还是说能够做到参数条件的完全可控(就像我们手写的 api 一样,一个接口进行了什么样的查询都是我们说了算)?
TommyLemon
2018-12-20 19:42:09 +08:00
@xiangyuecn
权限由后端控制,粒度细分到 每种角色、每种操作、每张表、每条记录,所以并不会出现越权访问的问题。
非开放请求(增删改,限制性查询)由后端控制参数 JSON 的数据和结构,所以非开放请求是后端说了算。

至于 开放请求( get 查数据,head 统计数量),返回 JSON 的数据和结构都是前端说了算。

需要事务 或 对安全性要求高 的用 非开放请求,其它用开放请求。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.1
pexcn
2018-12-20 22:43:50 +08:00
比 star 数....
感觉跟 hibernate 还是没得比...
TommyLemon
2018-12-20 23:40:34 +08:00
@pexcn
Star 早就超过了,怎么没得比呢?上面的截图你不信的话可以 GitHub 上分别看下 APIJSON 和 Hibernate 的。

APIJSON 是增量更新,只更新传过来的非 null 字段;
github.com/TommyLemon/APIJSON/blob/master/Document.md#3.1

Hibernate 默认全量更新,需要麻烦的配置才能实现增量更新
blog.csdn.net/u012038649/article/details/52587404/


APIJSON 关联查询非常容易实现,
还支持自动化 JOIN,包括 LEFT JOIN, INNER JOIN 等 SQL JOIN,
还有可跨数据库的应用层联表 APP JOIN,
全都不用后端写代码,前端传对对应的参数即可。
github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2

比 Hibernate 注解 @OneToMany, @ManyToOne 等 或 写 HQL 好用很多
blog.csdn.net/kd_bright/article/details/79528818
br00k
2018-12-21 01:19:37 +08:00
看着不错。有考虑支持 mongodb😂
blless
2018-12-21 01:37:01 +08:00
我觉得你对 API 有误解…我们公司对于 API 的定义就是精确接口调用,类似 DRY 原则,一个接口只干一个接口的事。按你这样设计我任何接口都可以强行拼接在一个 API 里面。API 设计出来就是让其他人用的,你这套设计我感觉只是自己方便而已,别人调用还要学习成本。我要自己方便我完全可以一个 model 直接生成服务端客户端代码,总之感觉还是一个挺鸡肋的东西… star 数不能说明什么,我记得有个 go web 教程有 2w7 star …
diggerdu
2018-12-21 01:47:23 +08:00
支持国产开源项目

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/519237

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX