完爆Facebook/GraphQL，APIJSON全方位对比解析(一)-基础功能

相关阅读：

完爆Facebook/GraphQL，APIJSON全方位对比解析(二)-权限控制

完爆Facebook/GraphQL，APIJSON全方位对比解析(三)-表关联查询

自APIJSON发布以来，不断有网友拿来和Facebook的GraphQL对比，

甚至有不少人声称“完爆”APIJSON。

然而事实正好相反，本系列博客将以大量真实依据来证明，

APIJSON“完爆”GraphQL！

后端接口和文档自动化，前端(客户端) 定制返回JSON的数据和结构！

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

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

特点功能

在线解析

• 自动生成文档，清晰可读永远最新
• 自动生成请求代码，支持Android和iOS
• 自动生成JavaBean文件，一键下载
• 自动管理与测试接口用例，一键共享
• 自动校验与格式化JSON，支持高亮和收展

对于前端

• 不用再向后端催接口、求文档
• 数据和结构完全定制，要啥有啥
• 看请求知结果，所求即所得
• 可一次获取任何数据、任何结构
• 能去除重复数据，节省流量提高速度

对于后端

• 提供通用接口，大部分API不用再写
• 自动生成文档，不用再编写和维护
• 自动校验权限、自动管理版本
• 开放API无需划分版本，始终保持兼容
• 支持增删改查、模糊搜索、正则匹配、远程函数等

视频演示：i.youku.com/apijson

[以下Gif图看起来比较卡，实际在手机上App运行很流畅] 
  

项目主页: github.com/TommyLemon/…

完爆Facebook/GraphQL，APIJSON全方位对比解析(一)-基础功能

APIJSON和GraphQL既有相通的功能，又有各自的特色功能。

其实，不管是以APIJSON还是GraphQL作为标准来说，这都不公平。

好在后端的大部分工作就是对数据库的增删改查，

几乎所有的API都是基于数据库的功能来实现的，

那么我们以数据库的功能作为标准就是一个很好的选择。

就以目前最流行的开源数据库MySQL为例吧：

如图所示，MySQL的基础功能中：

GraphQL仅支持极少的几个，而且全都要后端手动实现；

但APIJSON全都支持，而且全都是自动化的实现！

返回字段：

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一样的状态码，还是熟悉的配方，还是熟悉的味道。

未完待续...

创作不易，右上角点Star支持下吧，非常感谢^_^

github.com/TommyLemon/…