iT邦幫忙

2021 iThome 鐵人賽

DAY 7
0
Modern Web

不只是串串API,新手前端30天系列 第 7

DAY07 - API架構分享

其實大家可能都有自己的API架構方式,不過我這邊就是分享我目前在Web端撰寫API時,在架構上和開發時會注意的事情,跟大家分享,也歡迎各位大大互相交流~~~

API需要什麼架構?不是用到的時候打API就好了嗎?其實程式要怎麼寫都可以,但就差在寫法後續帶給你的會是痛苦加班還是快樂下班XD 這邊就來分享一下可以離快樂下班進一點的撰寫原則~

ps. 後續範例皆以vue.js搭配axios的程式為例

原則1 把所有API用統一一隻檔案控管,要使用的時候在各自引用

在製作前端畫面的時候,每個不同頁面,都會有很多需要串接API取得資料的地方。若每個頁面都分開打API取得資料,到時候要做管理的時候,就會變得很麻煩。
Ex.取得書本列表API,我在A、B、C頁面各呼叫一次,如果之後取得書本列表的API URL或參數有修改,那我就需要在各個頁面調整。

統一一個頁面做API控管,有API相關的新增修改,就統一找這個檔案,會讓後續的新刪修都一目了然也更好管理。

  • 特別獨立一個api.ts的檔案,統一管理API

  • 在需要的各頁面中(ex.頁面A/頁面C),引用同一來源的API function

原則2 共用的東西統一管理

其實是寫程式的時候應該都要有的概念,當東西開始要重覆寫好幾次的時候,就應該要把它整合成統一的變數,讓之後修改只要統一改這個變數就好了

2-1 基礎設定、路徑統一管理

API的基礎設定、還有各個類別的路徑可以統一管理,之後若要調整修改就可以很快地找到修改

2-1 錯誤處理統一管理

錯誤處理也可以用統一的function,讓所有API呼叫有錯誤時,都呼叫此API錯誤處理的function。
提到錯誤處理,也釐清一下後端的錯誤處理回傳方式,當API有錯時,錯誤代碼有兩種給法:

WAY1 - 回傳 http status code (參考連結)

當各個API有錯誤時,API傳回給前端的錯誤代碼是以http status code為標準。
例如:apiBookList有權限的錯誤,後端會直接用http status code - 403沒有權限的錯誤代碼回傳給前端。 若apiBookList中,前端的參數傳遞的錯誤就給400(Bad Request)的錯誤代碼。

WAY2 - 自定義不重覆的error code

後端提供一個error code的代碼,並把所有不同錯誤的編號,回傳給前端自定義的錯誤代碼。

其實兩種方式都可以,只要和後端討論好即可。但我自己可能比較喜歡用第二種方式。原因是:如果使用http status code,若有兩隻API有同樣的http status code但要做不同的錯誤處理,那就需要再額外判斷是哪一隻API
ex.apiBookList 和 apiAddBook 都會有 錯誤的 http status code 400,但apiBookList的400可能表示的是排列的方式沒有定義;apiBookAdd的400可能表示有必填的欄位沒傳給API。這就是同一種status code但不同API代表不同的意義。因此需要知道是哪一隻API才能判斷顯示的錯誤訊息或接下來該顯示的UI畫面或流程。

  • 回傳 http status code,相同status code要不同處理時需多判斷API是哪隻

  • 將所有不同的錯誤,定義成新的錯誤代碼,只判斷錯誤代碼,即決定錯誤處理行為

原則3 區分環境

在開發時,基本上都會有正式環境、測試環境、開發環境。不同的環境,可能會有不同的API Path或是不同的API Base setting。這也是在api統一管理時,可以一起加入撰寫的。

以上就是我的API幾個小小的管理原則跟注意的方向的心得,可能也不是真的很完善,也歡迎大家一起分我分享怎麼管裡可以更優化~
一起朝著未來修改程式可以快樂下班的路上邁進,我也還在努力RRR~~~


上一篇
DAY06 - API串接常見問題 - CORS - 解決CORS問題篇
下一篇
DAY08 - 自製MOCK API,讓你開發更方便
系列文
不只是串串API,新手前端30天30

尚未有邦友留言

立即登入留言