前端工程師心裡 OS：「其實我是想要空等的。」

大綱

1. 在正式 API 完成前，如何讓未來要串接的工程師不要空等？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 Mock Server 是什麼？學它有什麼好處？
   • 2.1 用 Postman 建立 Mock Server
   • 2.3 設計 Mock Server Response
   • 2.4 設定 Environment 讓你快速切換執行環境
   • 2.5 匯出 API documentation 給同事使用指引
   • 2.6 讓 Mock Server 變成私有的

1. 在正式 API 完成前，如何讓要串接的工程師不要空等？

1.1 面試官為什麼會問？

這問題是想了解你現在的工作是如何運行的，因為許多專案都採取前後端分離的架構，前端常常要等後端完成後才能串接，如果後端提供的服務不穩定，又或是沒按造需求規格開發就容易導致前端空等。

1.2 面試官想從答案確認什麼？

• 你現在工作時，前端與後端是如何協作的
• 你有用什麼工具，讓前端不用等你寫完 API 就能提前串接
• 你有提供什麼文檔供前端串接時參考
• 如果回答的是某個工具（ex：Postman），會再詳細詢問有使用到工具的哪些功能

1.3 筆者提供的簡答

我會先依照需求規格整理出一份讓雙方共同遵守的開發文檔，同時使用第三方驗證工具「Postman」建立 Mock Server，並根據 Request 的參數給予對應的 Result 結果，讓前端不需要等後端 API 完成後才能開始串接的作業。

2. 回答問題所需具備的知識

市面上提供 Mock Server 以及產生 API doc 的工具很多，不過「Postman」是筆者用起來最順手的；Postman 除了 API 的基礎測試外，還有許多加速工作效率的功能，就讓我們透過這篇文章讓自己的 Postman 更專業吧！

2.1 Mock Server 是什麼？學它有什麼好處？

在前後端分離的架構下，前端在完成網頁版面佈局後，需等待後端完成 API 才能做後續的開發；為了不讓前端在這段時間偷懶苦等，Mock Server 應運而生！它能回傳自訂的資料結構供前端使用，等後端完成 API 後，前端只需要切換網址就能使用真實資料。

除了上面的原因外，如果你開發環境的後端 Sever 不太穩定常常罷工，Mock Server 也能保證你的工作效率不受影響，畢竟不可能每次都等到 Server 修好後再工作吧？

2.2 用 Postman 建立 Mock Server

Postman 改版非常快速，你看到的畫面可能跟我有些許不同

• STEP 1： 建立 Mock Server

  1. New > Mock Server

     

  2. Create a new Collection > input url > Next
     如果不是選擇已經存在的 API Collection，就需要至少填寫一個 Request URL 讓 Collections 有初始化的 API Request

     

  3. 給 Mock Server 取個名字，並建議你勾選儲存 mock server URL 到環境變數的選項。

     

• STEP 2： 檢查 Mock Server 是否建立成功

  1. 建立成功後便可以在「Mock Servers」的分頁中看到剛剛建立的 Server，點進去後能看到這個 Sever 的網址。

     

  2. 接著我們到「Environments」的分頁確認，mock server URL 是否有儲存到環境變數，

     

2.3 設計 Mock Server Response

在 Mock Server 建立後，我們要設計不同 API Request 回傳的資料結構。

• STEP 1：先用 Request 的 Default example 來了解使用方式

  1. 到「Collections」的分頁找到剛剛初始化的 Request， {{url}}會帶入環境變數所以右上角請選擇剛剛建立的「Mock_User」，按下「Send」後你會發現下面的 Response 一片空白，這是因為我們還沒設定 Mock Server Response。

     

  2. 在左側 Request 下面有一個「Default」，它就是用來自訂 Response 資料結構的 example，這邊我們用 JSON 格式寫個簡單的 Response example 後按「Save」。

     

  3. 回到剛剛的 Request，按下「Send」後會發現 Response 的資料結構跟剛剛填寫的範例相同。

     

• STEP 2：新增其他的 Response example

  1. 除了最初的 Default 外，我們還可以自己新增其他的 Response example。

     

  2. 可以透過加入 Params 讓這個 Request 有不同的 Response，這裡我們新增「error」、「correct」這兩個 example 並加入「control_res」這個 Params 來做示範。

     在「DESCRIPTION」填寫的資訊會顯示在 API 文件上，寫清楚一點不但方便自己記憶，也更容易讓合作者了解。

     

     

  3. 回到剛剛的 Request ，我們在「control_res」填入不同的 VALUE，按下「Send」就會看到對應的 Response 嚕～

     

     

2.4 設定 Environment 讓你快速切換執行環境

這是 Postman 重要的功能之一，它可以加快開發速度，讓你不用為每個環境都建立一個 Request。

• 如果沒設定會發生什麼蠢事？

  

  有沒有覺得上面這張圖片看起來很蠢，在了解 Environment 怎麼設定前，我的 Collections 就是這麼的複雜；因為開發時通常環境會分成：「Local、Dev、QA、Prod」，如果每新增一個環境你就複製一份，到最後你會無法進行妥善管理。

• STEP 1：新增 Environment
  之前在建立 Mock Server 時其實就已經用到了 Environment，這裡我再詳細的跟大家說這個東西的好處。
  請先到「Environments」的分頁按下「＋」的按鈕，接著輸入名稱來新增環境（我用 local_server 做示範）。

  

• STEP 2：設定常用的 Environment variables

  • url
    這個是最實用的環境變數，讓你只需要調整 Request 的 Environment 就快速切換網址做測試。

  • login_user、login_password
    每個環境的使用者登入資訊通常略有不同，且大部分的 API 都需要透過登入取得 token 才能使用，把他們加入環境變數可以加速你的測試。

    警告：不建議把正式機的 password 加入環境變數，且測試機的 password 不要用平常自己會用的密碼，不然資安很危險的，都已經可以偷懶用 Environment，密碼自己去產生一組吧。

  

• STEP 3：在 Request 使用 Environment variables
  想在 Request 中使用 Environment variables 只需要用 {{your_env_var}} 包起來就好，另外右上角記得要切換到正確的 Environment 才會帶入相應的資料喔！

  

2.5 匯出 API documentation 給同事使用指引

相信後端工程師有一個共同經驗，無論你的 API 文件寫得再清楚、功能執行的再穩定；到了同事手中卻常常被說不能 Work，緊張的你檢查很多遍也找不出問題，百思不得其解的抵達同事座位後，才發現他原來漏了某個參數。

如果你有這樣的經驗，Postman 內建的 API documentation 能拯救你，讓你在 Publish 文件後可以跟同事幸福快樂的生活。

• STEP 1：View documentation
  選擇想要產生文檔的 Collection，按下「View documentation」後文檔就會顯示在右側，你可以透過切換右上角的環境變數來檢視文檔。

  

• STEP 2：Publish documentation

  1. 當你確定文檔內容都沒問題後按「Publish」。

     

  2. 接著會要你調整一些參數，調整完後建議先用左側的「Preview Documentation」自己確認看看是否符合。

     

  3. 確認一切都沒問題後按下「Publish Collection」就發布出去嚕～

     

• STEP 4：Share API Doc URL
  你可以將 URL 複製起來分享給你的合作夥伴，如果你想把這份文檔下架，按「Unpublish」即可。

  

2.6 讓 Mock Server 變成私有的

前面在建立 Mock Server 時，不知道有沒有人注意到「Make mock server private」的選項，在做這個設定前 Mock Server 的 URL 都是公開的，如果你想為自己的 Mock Server 多一層防護可以跟著下面步驟操作：

• STEP 1 : 編輯 Mock server

  1. 在「Mock Servers」分頁打開之前創建的 Server，按下「Edit」。

     

  2. 將「Make mock server private」打勾並按下「Save changes」。

     

  3. 回到之前的 Request，你會發現按下「Send」後會回傳錯誤訊息，這是因為現在 Mock Server 都需要添加 API key 到 Request 的 Header 才能使用。

     

• STEP 2 : 產生 Postman API key

  1. 進去這個 網址 ，點擊「Generate API key」。

     

  2. 填上用來識別這個 API key 的名稱後按下「Generate API key」。

     

  3. 接著請複製這個 API key，上面已經警告你這是唯一見到它的機會了。

     

• STEP 3：將 API key 加入 Environment
  因為日後 Mock Server 的所有 Request 都需要這個 API key，所以我們把他加入 Environment，變數名稱為「x-api-key」。

  

• STEP 4：在 Request 的 Header 加上 x-api-key
  最後回到 Request，在 Headers 的分頁下加入「x-api-key」這個參數並將環境變數 {{x-api-key}} 作為值，最後按下「Send」就能看到正確的 Response 回傳嚕！

  

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 讓你的 Postman 更專業(筆者部落格)

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

一、建立 Mock Servers
  🤔 為什麼需要學習這個技術？
  STEP 1：建立 Mock Server
  STEP 2：設計 Mock Server response
二、設定 Environments
  🤔 如果不了解怎麼設定會發生什麼蠢事？
  STEP 1：新增 Environments
  STEP 2：設定常用的 Environments variable
  STEP 3：在 request 使用 Environments variable
三、匯出 API documentation
  🤔 為什麼同事常常說我正確的api有問題？
  STEP 1：view documentation
  STEP 2：publish documentation
四、補充說明
  🤫 讓 Mock server 變成私有的

一、建立 Mock Server

🤔 為什麼需要學習這個技術？

過去在前後端分離的架構下，在 api 規格開出來後前端需等待後端完成 api 後才能做後續的開發；為了不讓前端在這段時間偷懶😏，Mock server 應運而生！他能回傳假資料供前端使用，等後端完成 api 後他只需要切換 end point 就能使用真實資料。

除了上面的原因外，如果你開發環境的 api sever 不太穩定常常因不明原因工作異常，Mock server 也能保證你的工作效率不受影響，畢竟不可能每次都等到 Server 修好後在工作吧？

STEP 1：建立 Mock Server

Postman 改版非常快速，你看到的畫面可能跟我有些許不同

如果不是選擇已經存在的 api Collection ，需要至少填寫一個 Request URL 讓Collections 有初始化的 api Request

給 Mock server 取個名字，並建議你勾選儲存 Mock server URL 到環境變數的選項。

建立成功後便可以在『Mock Servers』的分頁中看到剛剛建立的 Server，點進去後能看到這個 Sever 的網址

因為剛剛有儲存 Mock server URL 到環境變數，我們到『Environments』的分頁做個確認

STEP 2：設計 Mock Server response

在『Collections』的分頁我們能找到剛剛初始化的 request， {{url}} 會帶入環境變數所以右上角請選擇剛剛建立的『Mock_User』，按下『Send』後你會發現下面的 response 一片空白，這是因為我們還沒設定 Mock Server response。

你可以看到 request 下面有一個『Default』，他就是用來填寫假資料的 example，下面我們用 JSON 格式寫個簡單的 response 範例後按『Save』

再回到剛剛的 request 按下『Send』就發現會回應剛剛寫的 response 呢！

除了自動產生的 Default 外，我們還可以自己新增其他的 example

可以透過加入 Params 讓這個 request 有不同的 response，這裡我們新增『error』、『correct』這兩個來做示範

在 Params 填寫的 DESCRIPTION 日後會顯示在 api 文件上，如果可以也請盡量寫清楚

回到剛剛的 request ，我們將 control_res 加入『Params』，依據 VALUE 的不同按下『Send』就會看到對應的 response 嚕～

二、設定 Environments

🤔 如果不了解怎麼設定會發生什麼蠢事？

有沒有覺得上面這張圖片看起來很蠢😅，在了解 Environments 怎麼設定前，我的 Collections 就是這麼的複雜😇，因為寫程式時通常環境會有：『本機、開發機、測試機、正式機』，如果每新增一個環境你就複製一份，到最後你會無法進行妥善管理；更何況大多數的 api 其實只有網址的差異而已。

STEP 1：新增 Environments

之前在建立 Mock Server 時其實就已經用到了 Environments，這裡我在詳細的跟大家說這個東西的好處

到『Environments』的分頁按下『＋』的按鈕，接著輸入環境的名稱即可(我用 local_server 做示範)

STEP 2：設定常用的 Environments variable

url：這個是最實用的環境變數，讓你只需要調整 request 的 Environment 就快速切換網址做測試

login_user、login_password：每個環境的使用者登入資訊通常略有不同，且大部分的 api 都需要透過登入取得 token 才能使用，把他們加入環境變數可以加速你的測試。

P.S 不建議把正式機的 password 加入環境變數，且測試機的 password 不要用平常自己會用的密碼，不然資安很危險的，都已經可以偷懶用 Environments，密碼自己去產生一組吧。

STEP 3：在 request 使用 Environments variable

想在 request 中使用 Environments variable 只需要用 {{your_env_var}} 包起來就好，另外右上角記得要切換到正確的 Environments 才會帶入相應的資料喔！

三、匯出 API documentation

🤔 為什麼同事常常說我正確的api有問題？

相信後端工程師有一個共同經驗，無論你的 API 文件寫得再清楚功能執行的再穩定；到了同事手中卻常常被說不能 work，緊張的你檢查很多遍也找不出問題，百思不得其解的抵達同事座位才發現他原來漏了某個參數。

如果你有這樣的經驗，Postman 內建的 API documentation 能拯救你，讓你在 publish 文件後可以跟同事幸福快樂的生活。

STEP 1：view documentation

選擇想要產生文檔的 Collection，按下『view documentation』就會顯示在右側，同時你可以透過切換右上角的環境變數來檢視文檔。

STEP 2：publish documentation

當你確定文檔內容都沒問題後按『Publish』

接著會跳出一個網頁讓你調整一些參數，調整完後建議先用左側的『Preview Documentation』自己確認看看是否符合

確認一切都沒問題後按下『Publish Collection』就發布出去嚕～

你可以將 URL 複製起來分享給你的合作夥伴，如果你想把這份文檔下架，按『Unpublish』即可

四、補充說明

🤫 讓 Mock server 變成私有的

在前面 Mock Server 時不知道有沒有人注意到有『Make mock server private』的選項，這做這個設定前這個 mock server 的 url 都是公開的，如果你想為自己的 mock server 多一層防護可以這樣做

STEP 1 : 編輯 Mock server

從『Mock Servers』分頁打開之前創建的 Server，按下『Edit』做設定

將『Make mock server private』打勾並按下『Save changes』

回到之前的 Request，你會發現按下 Send 後會回傳錯誤訊息，這是因為現在 Mock server 都需要添加 api key 到 request 的 header 才能使用

STEP 2 : 產生 Postman API key

進去這個 網址 ，點擊『Generate API key』

填上用來識別這個 API key 的名稱後按下『Generate API key』

接著請複製這個 API key，上面已經警告你這是你唯一見到他的機會了

STEP 3：將 API key 加入 Environment

因為日後 Mock server 的所有 request 都需要這個 API key，所以我們把他加入 Environment，變數名稱為『x-api-key』

STEP 4：request 的 header 加上 x-api-key

最後回到 request，在 Headers 的分頁下加入『x-api-key』這個參數並將環境變數 {{x-api-key}} 作為值後按下『Send』就看到正確的 response 回傳嚕！

爬蟲完成後沒發出通知，就像是黯然銷魂飯少了洋蔥

為什麼通知很重要？

1. 在爬蟲的運作完全自動化的狀態下你需要透過接收通知，知道爬蟲執行完畢
2. 通知的內容要簡述這次爬蟲的狀況，因為實際上使用者只有在要報告或是寫文章的時候才會去 Google Sheets 看爬蟲的詳細數據，平常他只需要知道爬蟲有沒有穩定執行就好

在通知這個部分我選擇使用 LINE Notify 作為範例，你在了解邏輯後也可以自己改為用 Slack、Wechat、Messager… 等通訊軟體來通知喔

今日目標

1. 取得 LINE Notify 權杖

2. 使用 POSTMAN 測試 LINE Notify

2.1 為什麼要先用 POSTMAN 測試 LINE Notify 呢？

2.2 用 POSTMAN 發出 LINE 的訊息

2.3 透過 POSTMAN 傳送錯誤參數來了解 HTTP狀態碼的意思

1. 取得 LINE Notify 權杖

1. 請以 LINE 帳號登入 LINE Notify，登入後選擇 個人頁面

   

2. 為了要獲得控制 LINE Notify 發訊息的權限，我們要 發行權杖

   

3. 在發行權杖的彈窗中，權杖名稱請填寫與功能相關的名稱，接收通知的聊天室可選擇 1對1、任意聊天室 這兩種，確認無誤後按 發行

   

4. 接著我們要將這組權杖(Token) 複製 下來

   

5. 關閉彈窗後能看到 已連動的服務中 有我們剛剛新增的服務

   

6. 同時你收到 LINE Notify 帳號啟用權杖的訊息

   

7. 將發行的權杖(Token)加入 .env 環境檔，在明天的教學會使用到

   .env.exmaple

   #放LINE Notify申請的權杖
   LINE_TOKEN='XXXXXX'
   

2. 使用 POSTMAN 測試 LINE Notify

2.1 為什麼要先用 POSTMAN 測試 LINE Notify 呢？

說明這個問題之前，我們先來探討為什麼 POSTMAN 會這麼被工程師推崇，在這我歸納成以下幾點：

1. 對 後端工程師 而言，可以向合作夥伴證明自己寫的 api 沒有在唬爛，真的可以 work
2. 對 前端工程師、App工程師、有使用 api 需求的人 來說，能在串接 api 前先用 POSTMAN 確認這些 api 真的可以 work
3. 有了這個工具作輔助，我們就能將前後端責任歸屬的很清楚。ex：如果 POSTMAN 上面可以正常 work，那前端就要去思考自己 api 哪裡沒串好
4. 工具操作難度極低，只需要對網路的世界有基礎的認知就能快速上手

所以我們先用 POSTMAN 測試 LINE Notify 的理由是：

1. 確保 LINE Notify api 執行所需的 Request 參數、Respone 的結果與說明書一致（這點非常重要，因為我看過很多 api 回傳的結構跟說明書完全不一樣）
2. 在一行程式都不用寫的狀態下測試所有的可能性
3. 在 POSTMAN 驗證後就能專心寫程式，因為如果程式無法發出 LINE 的通知一定是自己的問題

補充：

• POSTMAN 在工程師的世界中素有 API測試神器之稱，如果你對 POSTMAN 一無所知的話你可以先透過這篇文章了解一下他是做什麼的
• 他可以直接用 Gmail帳號登入在網頁使用，也能下載桌面版 App，相同帳號的操作記錄在兩邊都會同步

2.2 用 POSTMAN 發出 LINE 的訊息

1. 設定 Request 的參數

   • URL：https://notify-api.line.me/api/notify

   • Method：POST

   • Authorization：

     • TYPE：Bearer Token
     • Token：填入你剛剛在 LINE Notify 申請的權杖

     

   • Body：

     • form-data：

       key	value	DESCRIPTION
       message	來自寶寶的爬蟲通知	純文字(必填)
       stickerPackageId	2	貼圖的PackageId
       stickerId	144	貼圖的Id
       imageFile	icon.png	電腦上的圖片檔

     

     DESCRIPTION 是我對參數描述，實作上可以不避填
     如果你想深入的了解可以參考官方文件

2. 完成 Request 參數填寫後按下 Send 發出 LINE 訊息

   • 看到 Response 的結果，status 為 200 代表傳送成功

     

   • 在發行權杖的聊天室中，看到 POSTMAN 傳送的 訊息、貼圖、圖片

     

2.3 透過 POSTMAN 傳送錯誤參數來了解 HTTP狀態碼的意思

我們剛剛在 POSTMAN 的 Response 看到 HTTP狀態碼為 200，接下來我們故意做一些錯誤測試來看看會有什麼樣的 Response

請注意並不是每隻 api Response data 中的 status 都等於 HTTP狀態碼，只是 LINE Notify 剛好是依照這個邏輯顯示，我們可以用它來幫助我們對 HTTP狀態碼的了解

1. 不填寫 LINE Notify 的權杖

   • HTTP狀態碼為 401，代表需要授權才能使用

     

2. 在 Body 中不填寫 message 的參數

   • HTTP狀態碼為 400，意味伺服器收到無效的語法

     

透過上面的範例回傳的資訊，我們可以了解到不同 HTTP狀態碼的意思：200 代表成功、400可能是參數錯誤、401是沒有授權，當然 HTTP狀態碼不只這些，如果你想更深入的了解可以參考這篇文章

參考資源

1. [API連線測試]使用Postman測試LINE Notify的訊息推送
2. LINE Notify API Document
3. Postman 新手教學
4. HTTP 狀態碼一覽表

在許多人的幫助下，本系列文章已出版成書，並添加了新的篇章與細節補充：

• 加入更多實務經驗，用完整的開發流程讓讀者了解專案每個階段要注意的事項
• 將爬蟲的步驟與技巧做更詳細的說明，讓讀者可以輕鬆入門
• 調整專案架構
  • 優化爬蟲程式，以更廣的視角來擷取網頁資訊
  • 增加資料驗證、錯誤通知等功能，讓爬蟲執行遇到問題時可以第一時間通知使用者
  • 排程部分改用 node-schedule & pm2 的組合，讓讀者可以輕鬆管理專案程序並獲得更精確的 log 資訊

有興趣的朋友可以到天瓏書局選購，感謝大家的支持。

購書連結：https://www.tenlong.com.tw/products/9789864348008