@anyele 你好，请多多指教

@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。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。

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

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

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

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

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

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

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

@p1094358629
自动化接口与文档 ORM 库 APIJSON 提供 JFinal 的 Demo，叫 APIJSONFinal，SpringBoot 的 Demo 叫 APIJSONBoot
www.v2ex.com/t/568631

@luckylo 还有这么玩的啊，前两个项目注释非常全，文档也非常详细哦
https://github.com/TommyLemon

可以看下这个，5.9K Star 远超 Hibernate 追赶 MyBatis
https://i.v2ex.co/R8M9a4es.jpeg
技术改变世界,前后协同变革 自动化 ORM 可靠度高达 99.85%
https://www.v2ex.com/t/568631

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

@xianxiaobo 那得模拟得多真实才不会被封号 /笑哭

@liuhuansir 不是 APIJSON，是 APIJSONAuto，一个后端项目，一个前端项目，不一样的。

https://i.v2ex.co/G4aeLKzI.jpeg

自动化接口管理工具，自动生成 9 种语言代码、自动静态检查、自动化回归测试、自动生成文档与注释等。
点 Star 支持下吧 ^_^
https://github.com/TommyLemon/APIJSONAuto

博客 7.7W 访问量，只做原创
GitHub 9.9K Star，APIJSON 获奖
https://www.v2ex.com/i/6yCS4Bu7.png

https://my.oschina.net/tommylemon

@TommyLemon 看语言排行榜就知道了，Java 强势，但 Python 潜力很大的哦，
不用太过纠结，先都大概看看基础语法，哪个简单学哪个，反正只是辅助嘛

@TommyLemon Python 整体上比 Java 更接近 Node，更容易上手

@xiangyuecn 哈哈，被你召唤出来了。
APIJSON 提供 Java, Python, C#, PHP, Node, Go 语言版哦

前端用这个可以快速入门后端并快速实现功能（后端提供自动化 API，不写代码也能实现 80% 的需求）

https://i.v2ex.co/03CYKF2J.png
码云最有价值开源项目：后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
GitHub 右上角点 Star 支持下吧 ^_^
https://github.com/APIJSON/APIJSON