今日主題

想像一個情景，當前後端討論完API規格，後端興高彩烈的埋頭工作三天，然後前端表示沒事幹跑來關心一下...

今天的主題便是Postman提供的Mock server，透過事先定義好一些假資料，來模擬實際上真正API的行為，所以在討論出那層介面後，其實前後端都可以開工了。前端暫時先用假API串，後端則是根據訂好的規格吐出跟假API相同格式的資料，這樣開發到有一定的完成度，就能無痛進行整合(理想上啦...)

另外除了可以將前後端切開不會互卡之外，還能節省前端除錯的時間，像是有些API可能資料每次變化都很大，進而影響前端除錯，或是API來回的時間比較長，累積下來的時間也相當可觀，更不用說某些特殊組成的資料才會產生的問題，也是相當適合透過Mock server來幫忙。

話不多說，直接開始今天的挑戰來體驗Mock services的方便之處吧，挑戰開始前別忘了先到 Day 10: Mock services fork回自己的工作區唷。

挑戰開始

回到自己的工作區，打開今天的Collection，找到其文件並根據下列步驟進行操錯

• 建立模擬伺服器: 在Postman左邊的Mock Server分頁選擇建立在當前的Collection

  

• 設定模擬伺服器: 輸入名字 mockForChallenge，其他設定可以先不調整

  

• 複製URL: 建立完成後，會產生伺服器的Mock URL，將它複製起來

  

• 新增請求: 在資料夾Mock Services以Add request新增請求，並命名為mock call，而方法設定為GET，URL則填入剛剛複製的Mock URL，完成後試著Send發出請求看看，可以看到因為該API還沒有任何example，所以傳了錯誤訊息

  

• 將回應存成example: 將回應存成新的example，當然也可以自行新增

  

• 修改example: 滑鼠點擊剛剛新增出來的example項目，修改原本狀態碼為200，內容隨意填入，這邊我另外使用了Postman的隨機變數{{$randomFullName}}，這樣可以讓每次呼叫都有不一樣的內容

  {
      "message": "The first mock call.",
      "name": "{{$randomFullName}}"
  }
  

• 重新發送請求: 回到mock call請求，試著重新發送，這次就會看到該API回應了我們定義的假資料`，包含了狀態碼以及內容

  

上面的步驟簡單的新增了一個GET請求，到這邊就可以提供前端進行串接，當然也可以根據需求定義出不同狀況下的資料，也讓前端更容易去處理到可能的狀況。

今日回顧

今天透過簡單的流程，介紹了如何使用Mock services來讓前端不能偷懶不被後端卡住，不過其實目前也有很多服務比起Postman提供的更好用，但因為這系列主題是Postman，所以有機會的話會另開篇章來進行介紹。今天的延伸閱讀放在下方:

• Setting up mock servers

那麼，我們明天見~