Hi，大家好，今天是第8天，我們接續昨天的作業，先把公開區域的 router 完成。

saf.js（系統公開區域routing）

本程式目前預計有3個功能

1. 系統首頁，顯示目前可公開之客服紀錄 & 對應之 ajax api
2. 客服紀錄的詳細資料與辦理情形的顯示頁面 & 對應之 ajax api
3. 系統登入頁

程式碼說明

第29行的 「/viewcase/:guid」與第38行的「/jsapi/caseinfo/:guid」的網址宣告方式是 express 自訂的參數化網址的宣告方式，:guid 可被任合文字所取代，並在 router 中以 「req.params.guid 」取得該文字

router.get("/viewcase/:guid", async (req, res, next) => {
    res.render("cases", {
        guid: req.params.guid
    })
})
//呼叫 「/viewcase/aaa」=>> req.params.guid = aaa
//呼叫 「/viewcase/abcde123」 ==>  req.params.guid = abcde123
/*
呼叫 「/viewcase/aaa/bbb」，HTTP 404，網址不存在，因為 /viewcase 只能接一層網頁名稱
若要設計多層參數網址，需設定成 /viewcase/:參數1/:參數2/:參數3…
*/

第22行與43行的功用是若呼叫 model 時，出現錯誤時，router直接回傳 http 500 的狀態碼，並送出錯誤訊息，前端之後可以捕捉狀態碼與錯誤訊息以進行例外處理

express 接收參數的方式

眾所周知，http傳輸有分 post、get 與其他多種傳輸方式，express在參數接收時會依照傳輸方式不同因而接收方式也不同，撰寫程式時需注意，在此簡單列出接收方式

1. req.query.參數名稱：接收 get 之參數，會被轉為文字型態
2. req.body.參數名稱：接收 post 之參數，會被轉為文字型態
3. req.files.參數名稱：接收上傳檔案，會被轉為 FromFile 型態
4. req.params.參數名稱：接收參數化網址的參數值，因為是express自訂網址命名的特殊規則，所以不限制是接收get的參數使用或是post的參數使用

設計思路

1. 一般我在處理資料頁面的習慣，首先會抓出少量的資料，做成列表或是卡片的型式，呈現在前端上，所以會有 「/」和「/jsapi/listCases」這2支 router 產生，
2. 為了識別方便，我會將 ajax 呼叫的API，統一集結於 /jsapi 的網址下，若是需要登入才可使用的API，則會放置於 /mgr/jsapi 中
3. 多數與資料處理有關的 api，均設計以 post method 為主，至少不用將頁面參數嚗露在網址列上
4. 僅嚗露最低限度的參數在網址列上，而且統一以 uuid 文字做為傳輸頁面參數，早期很多人的習慣是用資料庫的自動編號做為傳輸之參數，其實是一種危險的行為，有心人士可以利用「猜號碼」的方式取得資料，因此資訊安全人員通常會建議採用無從猜測的 uuid 或是至少需進行 base64編碼才可以做為傳輸參數
5. 一般我會把邏輯運算、檔案讀寫、資料庫存取的動作，統一集中在 model 中，如程式碼中的 casedao，即為我另外定義之 model，因為將邏輯與 router 分離後，可以降低程式耦合度，單純化router的功能，以降低日後的維護門檻

結語

我們今天完成了第一支 router 的規畫與雛形，並分享了我平常在規劃&撰寫 router 時的常用作法，明天預計會先行撰寫前端之頁面與骨架的 model 的功能，讓我們明天繼續吧