RestQL 現代化的 API 開發方式

參考：

在現代的業務系統中，後端開發工作基本上可以被拆分為三項：

我們先來做個假設。

所以在上述假設場景中，後端工程師要編寫 3200 + 240 = 3440 個 api。而且這還不是全部，假如後端**需要 100% 的測試覆蓋，那麼工程師們就要寫至少 3440 個測試！

60 張表 = 3440 個 api + 3440 個單元測試

眾所周知，資料操作 api 的實現過程基本上是重複的，有的同學甚至認為這是低端的，體現不出工程師價值的工作，純粹的「體力活」。但是卻沒有乙個能真正解放生產力的方案。

儘管我們把資料庫抽象成了「關係型」資料庫，把運算元據的命令抽象成了 sql ，同時我們也有了 mysql 客戶端，甚至是 sequelize 這種非常方便的庫，也有「restful」api 命名規則，但是介面的實現從來都是需要工程師們自己用手敲出來的。

如果說我看得比別人遠，那是因為我站在巨人的肩膀上。

所以我們在現有的技術基礎上再抽象，把已有的東西重新組合起來，拼裝成乙個新的工具，幫助工程師從「體力活」中解脫出來，解放生產力。

最開始的時候，我們最先需要明確的問題就是：「我們需要什麼樣的工具？」或者說「這種工具要幫我們解決什麼問題？」。

實際上我們從剛才的假設中，已經可以得出結論：我們希望有乙個工具可以讓工程師免於編寫資料操作 api，把資料庫操作直接對映到 http restful api 上。

為了解釋「如何請求」，我們先從一些公認的規則出發，舉乙個例子，然後再從例子中抽象出一些規則。

注意：為了更便於理解，我們把所有的命名從客戶端一直穿透到資料庫，所以請不要糾結於我們在定義乙個 api 時名詞單複數的問題。

基本用例

幾乎所有的系統都會有乙個使用者表（user）。根據 restful 規則的約定，我們應該把訪問 user 表的 api 路徑定義為/user，並把 crud 的訪問方法對映到 http 協議中的四種方法：get、post、put、delete。

比如：如果 user 表有乙個關係表 feed，那麼我們的路徑就會再複雜一點：

上述的例子中還會衍生出其他的資料操作，不僅僅只有get，這裡不一一枚舉了。

抽象出規則

上一節中，列舉了要提供乙個表的資料訪問 api，大概要實現哪些路由。從這些列舉中，可以找出其中的規律，總結出一套規則。最終我們在「把能實現的路由，全部實現」的原則基礎上，開發了 restql 的 koa 版本。

支援的 http 方法：

支援的帶有 body 的 http 方法：

說明：

single路徑為返回值為單個物件的路徑，包括：

我們已經開源了 koa-restql，koa 應用開發者可以通過 npm 安裝它：

npm install koa-restql

然後在 koa 應用的**中引用 restql：

const koa       = require('koa')
const restql = require('koa-restql')
// build apis from `sequelize.models`
let restql = new restql(sequelize.models)

使用者可以通過querystring來修改引數。強烈建議使用qs對 querystring 進行解析，例如：

qs.stringify() // => a=1&b=2

restql 中的querystring僅有 3 條規則：

通常來說，我們有兩種方法實現訪問控制：

通過中介軟體

在 koa 應用掛載 restql 的 router 之前，可以實現乙個鑑權中介軟體，控制使用者的訪問許可權：

通過 restql 引數

在使用sequelize定義關聯時，我們可以設定restql引數，實現訪問控制。例如：