最近接到一個任務，要將現行的團險紙本投保作業，改為線上讓員工及眷數自己做加保，勢必就要提供一個線上環境，由於此專案是採用前後端分離架構，且前後端分別由不同部門所負責，而我是負責後端API的部分，要做的工作如下:
1. 了解這個新投保的業務邏輯，思考要如何導入現行系統中
2. 盤點公司現行的模組功能，若有可以沿用的功能就沿用，而不需要重新造輪子
3. 設計供這個系統的API，讓前端可以透過這個API取得所需資料
4. 隨時跟需求單位進行溝通，了解他們真正的需求是什麼
5. 不斷的反覆測試開發完成的功能是否符合預期
6. 不斷的debug
由於我第一次接觸規劃API的工作，也google了許多資訊，但大多找到的是API的概念、如何建立API的流程，對於已經具備API概念的我，沒有太大的幫助，因此記錄我遇到的問題以及解決方式，希望能幫助到跟我遇到同樣問題的人
簡單說明這個專案要做的內容如下:
上圖是簡單的示意圖，API看似少了許多，但原本剛開始規劃的API比這個還多，應該是說每一個頁面就至少有1個以上的API，經過盤點目前可沿用的API及不斷的收斂各種業務邏輯，才縮減到如上圖的API列表
由於此專案是我第一次接觸，加上又是一個SA(系統分析師)的角色，要做的事情複雜許多，除了要擔任溝通的橋樑，非常熟悉業務邏輯、系統架構外，更要了解程式撰寫上的規劃和彈性，以下分享幾個我在執行此專案上的重要環節 :
1. 直接與前端工程師溝通，看它們要什麼資料，後端思考要怎麼給?何時給?
一開始因為不懂，自己在那邊想很多和鬼打牆，直到與前端溝通後才知道不能看圖說故事，雖然前端有寫了份文件給後端，但還是不能以圖片和文字做溝通，因為很常會有「你以為的並不是對方以為」的情形發生，得知前端要的東西後，我們就可以思考要如何達成前端需求，看似要用現行模組還是額外另寫一個API
2. 列出前端要給我的、我要給前端的、前端自行處理的
可以依照以下範例方式做區分:
a. 前端要給我: 被保險人ID、商品ID
b. 我要給前端: 保單號碼、投保始期、投保終期、是否退休、是否可以加 保、是否為合法登入角色、錯誤訊息
c. 前端自行處理: 保障期間、保障內容、繳費類型
透過以上歸類可以知道 a 就是API中的傳入參數，b就是API中的回傳值，且傳入和回傳內容皆已JSON格式做處理，那至於c的部分，就是屬於較簡單的邏輯部分，交由前端那邊去做處理，後端這邊不需要做事
3. 思考每個API對應的前端頁面，以及呼叫時機
以下兩個API為範例:
可投保專案列表API 和 檢核被保人投保資訊API 就對應到如上圖被保人投保資訊頁面，但前者的呼叫時機是在一開始進入此頁面時呼叫，而後者的呼叫時機是在使用者填完欄位，按下確認投保後才執行呼叫，在規劃API時需要考慮呼叫的先後順序，因為有時候某個API會依據先前不同條件和狀態而有不同的行為
4. 業務邏輯上的收斂及效能考量
前端打API的次數越多，耗費系統效能就越多，因此我們會希望API越少越好，然而要如何縮減API的數量，就必須檢視一下業務邏輯，通常後端在做的都是CRUD(增刪查改)有在做資料庫相關的人應該會知道，如果前端要的資料這次剛好可以拿到，那就可以把下一階段API要做的事情合併給這階段的API，進而減少API的數量，亦可以減少對資料庫的操作次數，覺得抽象的話，我舉下列例子，在餐廳裡面，桌號A的客人點了雞排丼飯、烏龍麵，桌號B的客人點了雞排丼飯、日式鮭魚親子丼，出餐順序是先A再B，這時候廚師可以同時製作雞排丼飯，因為下一階段(桌號B)要的餐點，在此階段(桌號A)剛好是一樣的，因此可以一併處理，把冰箱比喻成資料庫，是不是就少一次到冰箱拿食物的時間資源了
回到本篇要探討的被保人資訊頁面，其實在檢核被保人投保資格API時，我們就可以先取得可投保專案列表資訊了，所以我們將此API合併到投保資格API裡面，這樣就可以少一個API了
以上是我目前想到的內容，若有新的內容會再持續更新囉
