Never Nop Tech

Never Nop Tech

創造意義,動手去做。

那些經歷過GraphQL、Restful、Custom API的日子

在這篇文的開始,我想先說一下「規範」、「說明文件」、「友善度」才是最重要的。

實驗,確定大體上沒有障礙再跑實際專案。

在此舉出「規範」、「說明文件」、「友善度」定義如下:

規範:為達成標準化,如輸入參數、回傳參數、型別限制、狀態碼。

說明文件:為彼此站在同一個基礎點上,避免關鍵人消失,方法失傳,無法維護。

友善度:團隊合作能不能被接受。

Custom API的日子:

每個API都有奇怪的命名,如api/get/BookById?name=5&id=50、api/modifyBook?code=5&id=50、api/modifyBookName?name=123,這造成了後續難以維護的問題,某人接手,也許會想說:「打掉重練」,然續仍是一樣的狀況;或是,承襲之前的傳統,繼續下去。

終於,有一個人發覺到不能再這樣下去,又有了下個階段。

Restful API的日子:

這段日子是最棒的日子,他們循從GET /api/Book、POST /api/Book/、PUT /api/Book/1、DELETE /api/Book/1 ,一切都看來很直覺,後續維護省略掉了找出這API的大方向,可以很快的找到修改點,於是就不用再浪費時間重寫了。

但又發現,Restful API實在對複雜條件搜尋造成了問題,要求多個API才能要到所要的資料。因此,又有下個階段產生。

GraphQL的日子:

這段日子,前段非常快速,後段沒有進度,因為隨著資料表的增長,除非是資料庫建構者,否則沒有人能夠快速組出他們彼此的關聯,而關鍵人消失了,這個系統也隨之廢棄,打掉重練。

GraphQL造成每個串接者都需要知道資料庫內部構造,若有其中一人失誤了,資料便會對不上。最終,搞得一團糟。

於是,又回到了Restful的日子

Restful的日子:

這段日子是最順利的,以Restful為基礎,團隊能夠接受的友善度進行規劃,基礎的GET /api/Book、POST /api/Book/、PUT /api/Book/1、DELETE /api/Book/1 外,以團隊基礎增加了GET api/allSpecialVersionBook,為特別的動作開出API,並撰寫文件,後人接手變得簡單,也比較沒有爭議產生。

最終,寫他們是為了完成目標,不會給你無限的時間,而不管在哪個階段,至少要能找到一種彼此能接受的適合方式。因為在外人眼裡,就只有他可以運作、他無法運作,而你至少該做個好選擇,讓你的團隊(包含自己)輕鬆一點。

然後,我個人想補一句,你不是最重要的,因為工程就是一個工具,你會讚揚一座房子還是讚揚蓋房子的那群人?