居然置顶了

有必要吗，跟传销似的，还付费置顶。。。开源项目写得好就会有人关注啊，你这样算啥。。

其实看功能挺可以的 PHP 版本的到时候可以考虑下 现在大家都发现了 装 B 或者说不负责任的话 代价是如此的小 而且根本很多人没有用过 认识过 上来就一顿贬低 讽刺 说了多少遍 举证举证!

@TommyLemon

表示很感兴趣，但是我没看太明白。简单来说是根据前端传的参数，生成 sql 然后返回 json 给页面？我理解的对吗

如果返回数据像密码需要显示*星号这个可以实现吗？

与老项目对接怎么样呢？比如有老项目是 spring boot 写的，controller 里面还有不少判断逻辑，应该怎么集成呢？

@mmdsun 对的，基本原理就是这样
https://github.com/APIJSON/APIJSON/issues/38

后端重写相关的方法即可，DemoSQLExecutor.onPutColumn 判断 table 和 column，把密码字段的值 改成 * 星号。


不需要管原来各个 API 的的各种判断逻辑哦，加上 7 个自动化 API，直接
return new DemoParser(RequestMethod.GET).parse(request)
即可，如果有统一的权限控制（ session/cookie/jwt 等），在调用前判断即可。

@stillyu 这种生成静态代码的工具很多了，但都有几个很大的缺陷：
1.只能生成基本的简单增删改查，有 复杂嵌套、JOIN，子查询 等就不行了。
2.很多时候不能满足需求，还得在生成的代码上改，才能满足 GROUP BY、count(*) 等需求。
3.接口改过后有了不少逻辑，需求改了，用新生成的接口去替换成本很高，还不如在旧接口上改。

APIJSON 是对每次请求动态生成 SQL，需求变了就改请求，调用后就会自动生成新的 SQL，
这样就不用改后端代码，大部分情况下总是能满足各种定制性的需求。
https://raw.githubusercontent.com/TommyLemon/StaticResources/master/APIJSON/Share/Process.png

@kiinlam 说的 “需求变化或后端擦屁股问题” 正是 GraphQL 和传统 RESTful 等方式的问题，
APIJSON 恰好能很好地解决，大部分情况下总是不改后端代码就能满足需求。

APIJSON 怎么做复杂请求？
https://www.zhihu.com/question/61648519

你们可以在 APIJSONAuto 自动化接口管理工具上试试，任意调整数据和结构，
只要 请求符合 APIJSON 的协议、数据库有对应的表和字段、有权限访问表和字段 就能自动化支持。
请求 JSON 最外层加 "@explain": true 就能查看每个对象内自动生成的 SQL。
http://apijson.org/

@kiinlam APIJSON 提供了自动化 JOIN （ LEFT, RIGHT, INNER 等 SQL JOIN 和 应用层连表 APP JOIN ）来优化性能
数组关键词
④ "join":"&/Table0/key0@,</Table1/key1@"
多表连接方式：
"<" - LEFT JOIN
">" - RIGHT JOIN
"&" - INNER JOIN
"|" - FULL JOIN
"!" - OUTTER JOIN
"@" - APP JOIN
其中 @ APP JOIN 为应用层连表，会从已查出的主表里取得所有副表 key@ 关联的主表内的 refKey 作为一个数组 refKeys: [value0, value1...]，然后把原来副表 count 次查询 key=$refKey 的 SQL 用 key IN($refKeys) 的方式合并为一条 SQL 来优化性能；
其它 JOIN 都是 SQL JOIN，具体功能和 MySQL,PostgreSQL 等数据库的 JOIN 一一对应，
"ViceTable":{ "key@:".../MainTable/refKey" }
会对应生成
MainTable ... JOIN ViceTable ON ViceTable.key=MainTable.refKey。

再强调一下 APIJSON 不生成任何静态代码，只生成动态的 SQL 语句，
前端改了 JSON 参数，后端就生成新的 SQL 语句， 满足新的需求，
不需要后端写任何代码来实现上面的说 模糊搜索、分组排序 等，
还有自动化 JOIN 也不需要后端写代码：
```js
{
"[]": {
"count": 10, // LIMIT 10
"join": "</User/id@", // Comment LEFT JOIN User
"Comment": {
"content~": "a", // content REGEXP 'a'
"@group": "momentId", //GROUP BY momentId
"@order": "date+" //ORDER BY date ASC
},
"User": {
"@column":"id,name", // SELECT id,name
"id@": "/Comment/userId" // ON User.id = Comment.userId
}
}
}
```
APIJSONLibrary 生成
```sql
SELECT `Comment`.*, `User`.`id`, `User`.`name` FROM `sys`.`Comment` AS `Comment` WHERE `Comment`.`content` REGEXP 'a'
LEFT JOIN (SELECT `id`, `name` FROM `sys`.`apijson_user`) AS `User` ON `User`.`id` = `Comment`.`userId`
GROUP BY `Comment`.`momentId` ORDER BY `Comment`.`date` ASC LIMIT 10 OFFSET 0
```

https://github.com/APIJSON/APIJSON/blob/master/Document.md#3.2

还有 字段限制(可选)、查询缓存、查询预判、性能分析、过载保护 等多方面的优化
https://github.com/APIJSON/APIJSON/issues/16

@fghjghf Protobuff, Thrift, Dubbo 等 RPC 协议主要不是为了方便，而是为了传输性能而生的，
虽然能生成一些接口实现与调用的代码，但并没有像 HTTP API 那样有成熟完善文档工具，
所以一般更适合内部使用，尤其是微服务间互相调用，对于前后端分离的项目，联调反而更麻烦。

项目好不好不知道，你这广告看上去十分令人不爽啊。。。

v2ex 上要等被喷得差不多了才会有理性的发言

我觉得项目蛮好的，那些说风凉话的，什么 star 没有参考价值的，你自己倒是写出一个来，自己十行代码八个 bug，对别人的代码倒是挑肥拣瘦，真是柠檬

厉害

不错的项目，看到好些人没仔细看明白就喷，来顶一下楼主

@glfpes 是的，自从 Star 可以买之后就完全没有参考价值了

项目蛮好的，值得一试。但这宣传风格和舌战群儒的架势。。。呃

几年前做过类似的框架。直接 nodejs mongoose mongodb，这种场景下没必要用关系型数据库。从前到后全程是 json 根本不用映射

@dk7952638 @tt67wq @ddup 感谢支持^_^
就像我一个前同事在 ofo 做运营，她和我说每投放一个城市的单车，都要先喂饱那些私占的人才有大量目标用户使用。
我这也是先被 各种角度、各种无脑、各种没依据、各种凭主观感受 喷过后，才终于有了一些理性客观的评论哈哈。

喷子无处不在 V 站也不例外
不过回复那些无脑喷的方式你可能处理的不太好
大部分人喷的应该是你对那些喷子的反击方式吧
比如 #23 你这种点评飞机需要造飞机的观点 就比较不合适
无视或者理性回复那些东西 用户对你的项目会更有好感

很早就关注过你这个项目了 当时一直在寻找前后端 协同工具，传统的 restful 接口 对于现在是不太适用了
GraphQL 用过 ，你这个也用过，但都是简单的 demo 试用 希望有相关权威能站出来，说说两个的优劣势吧

@ksssdh123 目前还没看到所谓权威的对比，这个 issue 里有几个网友评价了
https://github.com/APIJSON/APIJSON/issues/2