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

@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。

@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

@ooonme 你对 APIJSON 都没了解清楚就不要瞎评论了。
APJSON 就是一种 JSON 格式的 ORM 协议，APIJSONLibrary 就是基于这个协议实现的一个 ORM 库，
只负责将 JSON 对象解析为 SQL，以及校验权限。
https://github.com/TommyLemon/APIJSON/tree/master/APIJSON-Java-Server/APIJSONLibrary
至于 HTTP 请求，那是基于 SpringBoot 开发的 APIJSONDemo 实现了 7 个自动化 API，调用 ORM 库来实现 CRUD。
https://github.com/TommyLemon/APIJSON/tree/master/APIJSON-Java-Server/APIJSONDemo

JSON 对象难道不是对象？这么说 Sequelize，TypeORM 等一堆 JavaScript ORM 库都不能叫 ORM 库了。

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

还有
自动生成封装请求 JSON 的 Android 与 iOS 代码
一键下载自动生成的 JavaBean
多个测试账号、一键共享测试用例
等

附 开放源码、视频教程
GitHub 右上角点 ⭐Star 支持下吧 ^_^
https://github.com/TommyLemon/APIJSONAuto

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

分开好。
要写代码（注解、注释等）不只是增加开发工作量，还得重新部署才生效，后续维护也麻烦。

其它评论下周回吧

@clino
说的是最后生态内开源库的链接吧，
排版预览时还是正常的，发出来就没对齐了。

设计规范
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3

如何实现其它语言的 APIJSON ？
https://github.com/TommyLemon/APIJSON/issues/38

@TommyLemon
并不觉得“标题立的太高了”

1. 不用写代码 -- 后端不用写代码
“因为 APIJSON 是自动化的，后端不用写代码，就能自动解析前端传的 JSON 参数...”
标题太长可能显示不下，一大堆新闻资讯（包括开源相关的）的标题不都要精简提炼下？

2. 超 Hibernate -- Star 超 Hibernate
事实依据都放上来了，一开始就是那张 Star 趋势图，还带链接，
再不信的话，APIJSON 项目链接都给了，Hibernate 你也能找到(我发的可能你又不信了)，你都看下。

不是符合事实就 “早就铺天盖地的用起来了，根本用不着亲自宣传。”，
而是要有很大的影响力才能达到这个效果，一般开发者是 名企或名人 才行，可惜我都不是，只好自己宣传了。

@sagaxu
我说的是不改后端代码，这是前端发的 JSON 参数。

===============================================


1.用什么方式都能做，前提都是后端服务支持，只是传统方式要后端写代码支持，而 APIJSON 几乎没有成本，尤其是对于后端开发来说。

2.APIJSON 规范了：
页码(统一用 page 代替 pageNum, page_index, pnum 等),
每页数量(统一用 count 代替 pageSize, pcount 等 ),
搜索关键词（统一用 $, ~ 代替原来的 serach，searchKey, s, query, q 等）,
连续范围 Between and(统一用 % 代替原来的 start=1&end=2, s=1&e=2, from=1&to=2 等)
包含值(统一用 <> 代替原来的 contains, con, cts, include, ild, inc 等)
增加或扩展 (统一用 + 代替原来的 add, plus, pls, append, appd, appe 等)
减少或去除 (统一用 - 代替原来的 remove, reduce, delete, rmv, red, del 等)
比较运算 (统一用 > 代替原来的 gt, <= 代替原来的 lte，id != 1 代替原来的 "id": { "ne": 1 } 等 各种不直观的写法)
逻辑运算 (统一用 & 代替原来的 and, |(可省略) 代替原来的 or， ! 代替原来的 not 等 各种不直观的写法)
...
传统方式开发的接口，不同的人对以上的命名很可能不一样，甚至同一个人写的不同接口都有可能不一样，
前端需要针对每个接口去查看文档或找后端确定，如果复制另一个相似接口的调用代码，
而不改名称（以为搜索 key 都是 seachKey ），接口调不通最后确定是这种问题，不是很恼火？

APIJSON 对以上功能是强制这样写关键词 /符号的，不是的话，调自动化 APIJSON 是得不到正确结果的，
还可能返回具体的错误信息，例如
"GET 请求，字符 id= 不合法！ key:value 中的 key 只能关键词 '@key' 或 'key[逻辑符][条件符]' 或 PUT 请求下的 'key+' / 'key-' ！"
"id{}:range 类型为 Integer ！ range 只能是 用','分隔条件的字符串 或者 可取选项 JSONArray ！"


当然其它一些命名，例如字段名等不能抽象的东西确实是没法强制了，强制的话会导致满足不了业务需求。

3.你说的很对，但现实就有大量 PHP 等动态类型语言写的后端啊，我是见过空对象变成 [] 返回导致线上 App 挂掉的。
难道就视而不见，或者强制使用 Java，Go 等静态类型语言？谁有这个权利，还能承担这个风险？

而且即便是静态类型语言，也有部分后端开发者不遵守约定改掉类型的，开发与测试环境常见，
可能是原来的类型不满足需求，或者有代码洁癖，看不惯以前不一致的代码自己重构了，前端必须改代码来兼容。

用 APIJSON 低成本、低风险地简单解决不好吗？而且还是从源头上避免问题的发生。

4.不能，但问题是 APIJSON 起码能保证 自动化 API 是返回标准且统一的 状态码的，传统方式啥都保证不了，全靠人。
人都是懒的，能用自动化 API 简单解决的，他就不大可能会自己写，又因为大部分 CRUD 是能用自动化 API 做，
所以大部分 CRUD API 就能保证状态码标准和统一了。
至于调第三方的接口，如果是前端直接调用，则前端特殊处理；如果是后端调用，一般都是手动写的接口，
不管是前端特殊处理，还是后端转成标准的状态码，都是可行的。

5.业务逻辑、流程图又不是后端给前端的，这是产品需求给的。后端只是提供 API，告诉前端怎么调用。
至于 UML 图，基本只是后端用来描述表关系，内部交接的时候用下，前端不需要关心。

6.非常多，非常普遍，可能你所在的项目组是严格按照前后端约定好文档再开发接口，很好地落实了这个流程，
但大部分中小型企业，还真的比较少有 合理的组织、规范的流程、良好的落实、高素质的开发团队。
能用 APIJSON 低成本解决的问题，就不要用 高成本的管理 来死磕了嘛。

APIJSON 的规范统一的，你换项目、换公司还是一样，Learn once, write anywhere.
用传统方式，别说换公司、换项目、就是换个后端开发甚至只是换个接口，就很可能不一样了，得一遍遍学习和适应。

你觉得不是问题的问题，可能是你没注意到，或者你经历过的项目确实不存在，但不代表一大堆中小型企业啊。
如果都和你是一样的看法，怎么会有这么多人支持我呢？或许你的项目环境比较优越，以至于 “何不食肉糜？”


===============================================


一个项目从开源到普及是需要时间的，APIJSON 效果确实好，但还有大量业务的开发人员、企业都不知道不了解，
而且 APIJSON 确实也没有火到像 SpringBoot，Mybatis，Redis 等一样成为业内普遍认可的方案，所以还需要推广，
不太可能现在就有公司写到招聘广告里，但的确已经有一些公司、团队、个人在用了，我们经常在群里回答问题。

@chocotan 你确定是各方面？再仔细看看 25 楼我的回复，我都说了
"Hibernate 代码质量比 APIJSON 高，这点我是承认的，但 APIJSON 的代码质量我自认为也是超过平均水平的，
不服的话，用阿里的 P3C 规范对比下？"

我在另一个社区还提到
"Hibernate 使用率是远高于 APIJSON 的，毕竟从 07 年开源到现在都快 12 年了，APIJSON 才 2 年多一点。"
oschina。net/news/101787/apijson-3-1-0-released#comments

有句话说得很对，"人们总是只看到他们想看到的东西"

@chinvo
很不一样，Parse 是 SaaS 服务，类似的有 Firebase 以及国内的 LeanCloud 等，
它们主要是把业务放到了前端，后端只手写或者自动生成一些细粒度的 RESTful 接口，
很多需求往往要前端调用多个接口再自己组装并处理数据，
有的还提供自己的类似 SQL 的查询语言，例如 LeanCloud 提供的 CQL，功能限制大，官方文档说了：
与 SQL 的主要差异
不支持在 select 中使用 as 关键字为列增加别名。
update 和 delete 不提供批量更新和删除，只能根据 objectId （ where objectId=xxx ）和其他条件来更新或者删除某个文档。
不支持 join，关联查询提供 include、relatedTo 等语法来替代（关系查询）。
仅支持部分 SQL 函数（内置函数）。
不支持 group by、having、max、min、sum、distinct 等分组聚合查询语法。

以上都是 CQL 不支持的，但 APIJSON 全都支持。

另外 SaaS 应用场景基本只适合创业项目，
提供的功能都是受限于 SaaS 服务商（ Parse 开源了，定制性要好一些），
有了一定规模就非常有必要把后端推到重来了。
而且又因为绑定了服务商的服务，迁移困难。

APIJSON 完全开放源码，容易定制，还能很好地控制权限。


APIJSON 则是 JSON 转 SQL 的协议，基于 JSON 扩展而来，
开源项目中提供了 Java 的 ORM 实现，
还有其它作者提供了 Node.js, C#, PHP 的实现。

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

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

@TommyLemon
这里只是一个地方，还有我发的一些博客下，我在 Gitee 开源的项目下，都有很多提到 Swagger 的。
github。com/TommyLemon/APIJSON/issues/27

@TommyLemon 甚至有些和 APIJSON 根本就不是同类的项目，例如 Swagger。

@vinsa
不知道你的维度指的是什么。APIJSON 和 Hibernate 都是 Java 的 ORM 库，拿来对比有什么奇怪的？
而且我发布 APIJSON 后，也有很多网友拿来和其它开源库（ Hiberate，GraphQL, JPA 等）对比。