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

相關閱讀：

完爆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/…