自APIJSON发布以来，不断有网友拿来和Facebook开发的GraphQL对比，甚至不少人声称“完爆”APIJSON。
然而事实正好相反，本系列博客将以大量真实依据来证明，APIJSON“完爆”GraphQL！
APIJSON的口号是:
后端接口和文档自动化，前端(客户端) 定制返回JSON的数据和结构！
APIJSON的简介：
APIJSON是一种为API而生的JSON网络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的API。
能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。
通过自动化API，前端可以定制任何数据、任何结构！
大部分HTTP请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！
自动生成文档，清晰可读永远最新
自动生成请求代码，支持Android和iOS
自动生成所有JavaBean，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化JSON，支持高亮和收展
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度
提供通用接口，大部分API不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本
开放API无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等
https://github.com/TommyLemon/APIJSON
基础功能对比
APIJSON和GraphQL既有相通的功能，又有各自的特色功能。
其实，不管是以APIJSON还是GraphQL作为标准来说，这都不公平。
好在后端的大部分工作就是对数据库的增删改查，
几乎所有的API都是基于数据库的功能来实现的，
那么我们以数据库的功能作为标准就是一个很好的选择。
就以目前最流行的开源数据库MySQL为例吧：
返回字段：
GraphQL强制前端在请求里填写所有需要的字段名，用换行分隔。
{
key0
key1
...
}
例如
http://graphql.org/learn/queries/#arguments
{
human(id: "1000") {
name
height
}
}
而APIJSON则默认返回全部字段，可选 @column 来指定需要的字段。
"@column":"key0,key1,..."
例如
{
"User":{
"id":38710,
"@column":"id,name" }
}
试想一下，很多时候我们会有查询单个对象(用户详情User,动态详情Moment等)的需求，往往对象里的字段几乎全都是需要返回的。
即便是查询列表，像APIJSONServerDemo的Comment这种没有冗余字段的表里每个都要用啊！
GraphQL这种强制性的做法无疑会导致前端很多时候在很多对象里写10个以上的字段。
以它的JavaScript源码为例，简单Demo级别的Human里就得写6个字段！
https://github.com/graphql/graphql-js/blob/master/src/__tests__/starWarsSchema.js
{
human {
id
name
friends {
}
appearsIn {
}
homePlanet
secretBackstory
}
}
如果用APIJSON呢？就这么简洁：
{
"Human": {
}
}
状态码(APIJSON特有)：
GraphQL没有状态码！GraphQL没有状态码！GraphQL没有状态码！！！
这点非常奇葩，难以置信，但事实如此。
我们经常会碰到 登录超时或其它设备登录要强制当前用户下线、付款时可能有密码错误、余额不足等各种情况。
这些都需要一个和 操作成功(200)、其它错误 不一样的唯一标识，前端才能根据这些标识做不同的处理，
例如跳到登录界面，自动切换付款的银行卡等。
但现在GraphQL不提供状态码，也没看到其它的唯一标识！
所以前端除了能对错误进行提示，其它的操作根本不用想了！！！
而APIJSON就提供了和原来RESTful API一样的状态码，还是熟悉的配方，还是熟悉的味道。
未完待续...
APIJSON，让后端接口和文档自动化，前端(客户端) 定制返回JSON的数据和结构！
创作不易，右上角点Star支持下吧，非常感谢^_^
