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

TommyLemon-GitHub發表於2018-05-08
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/…

 

 

相關文章