解析SQL语法，再校验权限、结构、内容，最后再转回SQL， 不说性能问题，真要这么好搞业内也应该有不错的开源方案了。   而且SQL不能直观地反映返回JSON的数据结构， APIJSON就能做到看请求知结果，所求即所得。   APIJSON的 提取字段、远程函数 功能也不是SQL方案能方便地实现的。 还有 自动加注释、自动生成封装请求JSON的代码，用SQL方案实现也很困难，甚至根本不可能准确地实现。

 

为什么要用APIJSON？或者APIJSON有什么用？ https://github.com/TommyLemon/APIJSON/wiki######坏人######我就认为graphql是个超级kpi项目######你写sql从来不考虑执行时间么？看楼主只是一个前端吧，语言都是互通的，有个半天几本能上手开发，没必要去学。graphql虽然还没在业务上使用，从优点来看，可以非常优雅获取后台交互的数据，schema即是文档，便于维护（开发什么的有什么难的，维护才最麻烦，写一大堆鬼都看不懂的sql，到时候业务变动，连改都懒得改，直接重写，重写完发现，操效率低这么多，还得tmd的优化，最后发现连自己都看不懂的天书，让下一个接手的人继续上面的循环）。－－（一个在postgre上优化了n多次merge join到hash join的人，鬼知道自己怎么优化的，一次一次的尝试）######我并不是否定模型（schema）的作用，也认同可维护性带来的好处，只是觉得再早一门query language的优势在何处。 难道不能直接吧sql的语法作为query language，后端需要优化完全可以parse sql后拆分成n个sql执行都不重要。######APIJSON与GraphQL全方位对比解析(一)-基础功能 https://http://juejin.im/post/5ae80edd51882567277433cf APIJSON与GraphQL全方位对比解析(二)-权限控制 https://http://juejin.im/post/5b17518c6fb9a01e75463096 APIJSON与GraphQL全方位对比解析(三)-表关联查询 https://http://juejin.im/entry/5b4ff88f6fb9a04f914a8df5