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

27,215 阅读4分钟

相关阅读:

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

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

 

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

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

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

APIJSON“完爆”GraphQL!

 

APIJSON的口号是:

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

APIJSON的简介:

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

 

未完待续...

 

 

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

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

github.com/TommyLemon/…