APIJSON 3.4.9 发布,已入选码云最具价值项目

孤独的探索号
 孤独的探索号
发布于 2019年03月14日
收藏 106

APIJSON 3.4.0-3.4.9 更新内容:

  • 新增JFinal版Demo叫APIJSONFinal,SpringBoot版Demo改名为APIJSONBoot;

  • 全面兼容PostgreSQL;修复自动化JOIN和子查询的问题等。

  • 新增 >,<,>=,<= 比较运算;新增支持自定义主键名等功能。

APIJSON 简介

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

通过自动化API,前端可以定制任何数据、任何结构!
大部分HTTP请求后端再也不用写接口了,更不用写文档了!
前端再也不用和后端沟通接口或文档问题了!再也不会被文档各种错误坑了!
后端再也不用为了兼容旧接口写新版接口和文档了!再也不会被前端随时随地没完没了地烦了!


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


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


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


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

对于前端

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

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

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

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

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

对于后端

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

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

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

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

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

APIJSON 生态内项目:

  • APIJSONAuto 接口管理工具,自动生成文档与注释、自动生成代码、自动化回归测试、自动静态检查等

  • uliweb-apijson Python 版 APIJSON,支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite 等

  • APIJSON.NET C# 版 APIJSON ,支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite

  • apijson PHP 版 APIJSON,支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite 等

  • apijson Node.ts 版 APIJSON,支持 MySQL, PostgreSQL, MS SQL Server, Oracle, SQLite, WebSQL

  • APIJSONParser 参考 APIJSON 设计标准开发的一款 SQL 编译器框架

  • SpringServer1.2-APIJSON 智慧党建服务器端,提供 上传 和 下载 文件的接口

  • APIJSON-Android-RxJava 仿微信朋友圈动态实战项目,ZBLibrary(UI)+APIJSON(HTTP)+RxJava(Data)

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

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

https://gitee.com/TommyLemon/APIJSON

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:APIJSON 3.4.9 发布,已入选码云最具价值项目
加载中

精彩评论

小柑橘
从17年知道APIJSON开始,看着它一步步成长到今天,也见识到它年轻生命所拥有的强大力量;一路上离不开作者和其他贡献者的付出与坚持。👏👍👍
孤独的探索号
孤独的探索号

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈
APIJSON 对于前端
不用再向后端催接口、求文档
数据和结构完全定制,要啥有啥
看请求知结果,所求即所得
可一次获取任何数据、任何结构
能去除重复数据,节省流量提高速度

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki
wendal
wendal
会不会哪天就支持nutz了呢? 哈哈
MGL_TECH
MGL_TECH
只是客户端组织数据?我觉得有些概念混了,再也不需要接口了?是自己造数据吗?

最新评论(23

孤独的探索号
孤独的探索号

引用来自“宋五哥”的评论

@孤独的探索号 ,请教大神,目前的APIJSONBoot支持Oracle数据库吗?我看zip里面有个APIJSONBootOracle这个是Oracle版本?运行的时候getValue提示没有,这个的代码里面的libs是不是不是最新的?
对的,用这个,APIJSONBootOracle 里的 apijson-server.jar 确实不是最新
宋五哥
宋五哥
@孤独的探索号 ,请教大神,目前的APIJSONBoot支持Oracle数据库吗?我看zip里面有个APIJSONBootOracle这个是Oracle版本?运行的时候getValue提示没有,这个的代码里面的libs是不是不是最新的?
孤独的探索号
孤独的探索号

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈

引用来自“孤独的探索号”的评论

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

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki

引用来自“宇润”的评论

我觉得前端会认为后端偷懒,前端要更多的心智负担,哈哈。。不过我是后端,我喜欢

引用来自“孤独的探索号”的评论

后端偷了懒还顺便帮了前端省时省力省心,皆大欢喜啊

引用来自“kidfruit”的评论

@孤独的探索号 前端并没有省时省力省心,因为以前只用关心数据从哪个接口来,后端实现就行,现在前端需要自己去处理如何获取数据。这个后端肯定是喜欢的。

引用来自“孤独的探索号”的评论

后端把接口上传到 APIJSONAuto(可下载源码部署到内网),前端点开看就知道了,流程和以前一样,怎么还需要自己想如何处理获取数据?
你说的“后端实现就行“,说得轻松实际上哪里是这么简单的,不需要沟通返回字段和数据结构?甚至有时候传参都得扯皮半天。

传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

APIJSON:前端/客户端调用接口>前端/客户端解析返回结果


为什么要用APIJSON?前后端10大痛点解析
后端:零用时开发接口、零沟通零被打扰。
前端/客户端:内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。
后端不用写接口、也不用写文档就能提供"接口"和"文档",前端/客户端不用看"文档"就能调用"接口"。
APIJSON实现了前端/客户端要什么就返回什么,而不是后端给什么才能用什么,从根本上解决了:
1.浪费性能、流量和带宽
2.各种奇葩的缩写、混乱的命名
3.数据类型不稳定或随意改变
4.几百甚至上千个混乱的状态码
5.文档过时,与接口不同步
6.应用界面和接口强耦合难分离
7.版本迭代导致大量重复功能的接口
8.前端/客户端与后端扯皮
9.数据库操作不安全
10.开发流程繁琐周期长

https://github.com/TommyLemon/APIJSON/wiki

引用来自“kidfruit”的评论

你说的这些其实是有适用范围和场景的。

1、2、3、4、7、8、9、10这几条,正常的有组织的公司,都会有架构师明确规定各种接口的要求和规范,不会产生什么混乱,系统技术负责人也会定义好接口功能。
5 有swagger之类的工具实现。
6 后端写接口和用apijson的接口实际上一码事,并没有谁耦合度更高,都是接口依赖型。区别只是apijson把后端这一层往前端迁移了BLL的一部分。

而且你的下面这个流程明显有问题。接口、数据格式、文档应该是优于实现的,你先写后端再写前端当然会导致很多问题。
传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

正确的接口开发流程应该是
架构设计>接口设计>前后端分别并行实现>前后端分别独立调试>联调。如果前后端进度差距过大说明一开始项目经理在人力分配时不够合理,需要重新协调人力。

不是说你这个不好,只是面向的用户是有范围的。对于一个大型公司,有规范的接口实际上是更有利于整个公司各部门协调和产品迭代的,同时对于业务中台,接口包含了业务逻辑的组织,不是简单的取数据。apijson适合的是个人或者小团队使用,能够在人手紧缺,或者缺少总体设计和管理的时候提高效率,当公司有一定规模后,这套思路是不利于产品线发展的,所以不要过度鼓吹。
前端定制后端接口返回数据和结构的这种做法,APIJSON 也不是第一个,之前有微软的 OData,
最近又有个很火的 GraphQL 是 Facebook 出的,说明大厂也是需要这样的解决方案的。
https://github.com/TommyLemon/APIJSON/issues/63
孤独的探索号
孤独的探索号

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈

引用来自“孤独的探索号”的评论

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

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki

引用来自“宇润”的评论

我觉得前端会认为后端偷懒,前端要更多的心智负担,哈哈。。不过我是后端,我喜欢

引用来自“孤独的探索号”的评论

后端偷了懒还顺便帮了前端省时省力省心,皆大欢喜啊

引用来自“kidfruit”的评论

@孤独的探索号 前端并没有省时省力省心,因为以前只用关心数据从哪个接口来,后端实现就行,现在前端需要自己去处理如何获取数据。这个后端肯定是喜欢的。

引用来自“孤独的探索号”的评论

后端把接口上传到 APIJSONAuto(可下载源码部署到内网),前端点开看就知道了,流程和以前一样,怎么还需要自己想如何处理获取数据?
你说的“后端实现就行“,说得轻松实际上哪里是这么简单的,不需要沟通返回字段和数据结构?甚至有时候传参都得扯皮半天。

传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

APIJSON:前端/客户端调用接口>前端/客户端解析返回结果


为什么要用APIJSON?前后端10大痛点解析
后端:零用时开发接口、零沟通零被打扰。
前端/客户端:内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。
后端不用写接口、也不用写文档就能提供"接口"和"文档",前端/客户端不用看"文档"就能调用"接口"。
APIJSON实现了前端/客户端要什么就返回什么,而不是后端给什么才能用什么,从根本上解决了:
1.浪费性能、流量和带宽
2.各种奇葩的缩写、混乱的命名
3.数据类型不稳定或随意改变
4.几百甚至上千个混乱的状态码
5.文档过时,与接口不同步
6.应用界面和接口强耦合难分离
7.版本迭代导致大量重复功能的接口
8.前端/客户端与后端扯皮
9.数据库操作不安全
10.开发流程繁琐周期长

https://github.com/TommyLemon/APIJSON/wiki

引用来自“kidfruit”的评论

你说的这些其实是有适用范围和场景的。

1、2、3、4、7、8、9、10这几条,正常的有组织的公司,都会有架构师明确规定各种接口的要求和规范,不会产生什么混乱,系统技术负责人也会定义好接口功能。
5 有swagger之类的工具实现。
6 后端写接口和用apijson的接口实际上一码事,并没有谁耦合度更高,都是接口依赖型。区别只是apijson把后端这一层往前端迁移了BLL的一部分。

而且你的下面这个流程明显有问题。接口、数据格式、文档应该是优于实现的,你先写后端再写前端当然会导致很多问题。
传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

正确的接口开发流程应该是
架构设计>接口设计>前后端分别并行实现>前后端分别独立调试>联调。如果前后端进度差距过大说明一开始项目经理在人力分配时不够合理,需要重新协调人力。

不是说你这个不好,只是面向的用户是有范围的。对于一个大型公司,有规范的接口实际上是更有利于整个公司各部门协调和产品迭代的,同时对于业务中台,接口包含了业务逻辑的组织,不是简单的取数据。apijson适合的是个人或者小团队使用,能够在人手紧缺,或者缺少总体设计和管理的时候提高效率,当公司有一定规模后,这套思路是不利于产品线发展的,所以不要过度鼓吹。
简介的第一段就说明了适用范围和场景:
APIJSON是一种为API而生的JSON网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的API。
能大幅降低开发和沟通成本,简化开发流程,缩短开发周期。
适合中小型前后端分离的项目,尤其是互联网创业项目和企业自用项目。


能用技术低成本解决的问题,非得用高成本的管理来死磕嘛。
你能指望一大堆小公司在流程/规范上做好吗?
开发都是不停地赶需求,连文档都没时间好好写。
大公司就忽略掉吧,APIJSON并不是为它们开发的。

另外你可以看看 APIJSONAuto,比 Swagger 强大易用很多。
自动化接口管理平台,机器学习测试、自动生成代码、自动静态检查、自动生成文档与注释、做最先进的接口管理平台。
http://apijson.org/
kidfruit
kidfruit

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈

引用来自“孤独的探索号”的评论

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

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki

引用来自“宇润”的评论

我觉得前端会认为后端偷懒,前端要更多的心智负担,哈哈。。不过我是后端,我喜欢

引用来自“孤独的探索号”的评论

后端偷了懒还顺便帮了前端省时省力省心,皆大欢喜啊

引用来自“kidfruit”的评论

@孤独的探索号 前端并没有省时省力省心,因为以前只用关心数据从哪个接口来,后端实现就行,现在前端需要自己去处理如何获取数据。这个后端肯定是喜欢的。

引用来自“孤独的探索号”的评论

后端把接口上传到 APIJSONAuto(可下载源码部署到内网),前端点开看就知道了,流程和以前一样,怎么还需要自己想如何处理获取数据?
你说的“后端实现就行“,说得轻松实际上哪里是这么简单的,不需要沟通返回字段和数据结构?甚至有时候传参都得扯皮半天。

传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

APIJSON:前端/客户端调用接口>前端/客户端解析返回结果


为什么要用APIJSON?前后端10大痛点解析
后端:零用时开发接口、零沟通零被打扰。
前端/客户端:内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。
后端不用写接口、也不用写文档就能提供"接口"和"文档",前端/客户端不用看"文档"就能调用"接口"。
APIJSON实现了前端/客户端要什么就返回什么,而不是后端给什么才能用什么,从根本上解决了:
1.浪费性能、流量和带宽
2.各种奇葩的缩写、混乱的命名
3.数据类型不稳定或随意改变
4.几百甚至上千个混乱的状态码
5.文档过时,与接口不同步
6.应用界面和接口强耦合难分离
7.版本迭代导致大量重复功能的接口
8.前端/客户端与后端扯皮
9.数据库操作不安全
10.开发流程繁琐周期长

https://github.com/TommyLemon/APIJSON/wiki
你说的这些其实是有适用范围和场景的。

1、2、3、4、7、8、9、10这几条,正常的有组织的公司,都会有架构师明确规定各种接口的要求和规范,不会产生什么混乱,系统技术负责人也会定义好接口功能。
5 有swagger之类的工具实现。
6 后端写接口和用apijson的接口实际上一码事,并没有谁耦合度更高,都是接口依赖型。区别只是apijson把后端这一层往前端迁移了BLL的一部分。

而且你的下面这个流程明显有问题。接口、数据格式、文档应该是优于实现的,你先写后端再写前端当然会导致很多问题。
传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

正确的接口开发流程应该是
架构设计>接口设计>前后端分别并行实现>前后端分别独立调试>联调。如果前后端进度差距过大说明一开始项目经理在人力分配时不够合理,需要重新协调人力。

不是说你这个不好,只是面向的用户是有范围的。对于一个大型公司,有规范的接口实际上是更有利于整个公司各部门协调和产品迭代的,同时对于业务中台,接口包含了业务逻辑的组织,不是简单的取数据。apijson适合的是个人或者小团队使用,能够在人手紧缺,或者缺少总体设计和管理的时候提高效率,当公司有一定规模后,这套思路是不利于产品线发展的,所以不要过度鼓吹。
孤独的探索号
孤独的探索号

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈

引用来自“孤独的探索号”的评论

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

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki

引用来自“宇润”的评论

我觉得前端会认为后端偷懒,前端要更多的心智负担,哈哈。。不过我是后端,我喜欢

引用来自“孤独的探索号”的评论

后端偷了懒还顺便帮了前端省时省力省心,皆大欢喜啊

引用来自“kidfruit”的评论

@孤独的探索号 前端并没有省时省力省心,因为以前只用关心数据从哪个接口来,后端实现就行,现在前端需要自己去处理如何获取数据。这个后端肯定是喜欢的。
后端把接口上传到 APIJSONAuto(可下载源码部署到内网),前端点开看就知道了,流程和以前一样,怎么还需要自己想如何处理获取数据?
你说的“后端实现就行“,说得轻松实际上哪里是这么简单的,不需要沟通返回字段和数据结构?甚至有时候传参都得扯皮半天。

传统RESTful:后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

APIJSON:前端/客户端调用接口>前端/客户端解析返回结果


为什么要用APIJSON?前后端10大痛点解析
后端:零用时开发接口、零沟通零被打扰。
前端/客户端:内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。
后端不用写接口、也不用写文档就能提供"接口"和"文档",前端/客户端不用看"文档"就能调用"接口"。
APIJSON实现了前端/客户端要什么就返回什么,而不是后端给什么才能用什么,从根本上解决了:
1.浪费性能、流量和带宽
2.各种奇葩的缩写、混乱的命名
3.数据类型不稳定或随意改变
4.几百甚至上千个混乱的状态码
5.文档过时,与接口不同步
6.应用界面和接口强耦合难分离
7.版本迭代导致大量重复功能的接口
8.前端/客户端与后端扯皮
9.数据库操作不安全
10.开发流程繁琐周期长

https://github.com/TommyLemon/APIJSON/wiki
孤独的探索号
孤独的探索号

引用来自“wendal”的评论

会不会哪天就支持nutz了呢? 哈哈
哈哈,可以出这样一个 Demo
kidfruit
kidfruit

引用来自“宇润”的评论

这大概是前端很讨厌的东西吧,哈哈

引用来自“孤独的探索号”的评论

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

为什么要用APIJSON?前后端10大痛点解析
https://github.com/TommyLemon/APIJSON/wiki

引用来自“宇润”的评论

我觉得前端会认为后端偷懒,前端要更多的心智负担,哈哈。。不过我是后端,我喜欢

引用来自“孤独的探索号”的评论

后端偷了懒还顺便帮了前端省时省力省心,皆大欢喜啊
@孤独的探索号 前端并没有省时省力省心,因为以前只用关心数据从哪个接口来,后端实现就行,现在前端需要自己去处理如何获取数据。这个后端肯定是喜欢的。
wendal
wendal
会不会哪天就支持nutz了呢? 哈哈
孤独的探索号
孤独的探索号

引用来自“MGL_TECH”的评论

只是客户端组织数据?我觉得有些概念混了,再也不需要接口了?是自己造数据吗?
上面已经说了,提供了自动化增删改查 API,前端通过 URL 和 JSON 参数定制自己要的数据和结构,大部分接口后端不用再写
https://github.com/TommyLemon/APIJSON/blob/master/%E8%AF%A6%E7%BB%86%E7%9A%84%E8%AF%B4%E6%98%8E%E6%96%87%E6%A1%A3.md
返回顶部
顶部