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

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

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~~~