前端除了要切版與設計師的溝通之外，在資料串接的部分，就是與後端工程師溝通的時候了! 後端要怎麼把資料給前端呢？在開始串接前通常又會做哪些事呢？

01.API規格文件 - 前後端溝通的規則紀錄

後端開發完API後，會有一份API規格告知前端，通常會整理成文件有可能是word、也有可能是線上產的swagger API Document...

• swagger API文件範例 （取自 https://editor.swagger.io/ ）
  

• word API文件範例
  

但不論怎麼給，這份文API文件基本上會包含幾個部分：

1. URL(路徑): 要從API存取資料，當然最重要的就是要知道位置，不然要去哪裡拿資料呢

2. Method(方法):用什麼方法來使用這隻API，常見的如：GET 拿取資料、POST 新增修改資料、DELETE 刪除資料，還有其他像 PUT、UPDATE...

3. Parameters(參數):

   • header
   • path
   • Query

4. Request body:透過request body要把前端資料透過傳給API，通常用在POST的方法

5. Response body: API預期回覆給你的資料，最常見的格式為json格式

6. Error Description: 當有錯誤時，API會回傳給前端的錯誤代碼或訊息

02. 確認API是否有缺漏

拿到API文件後要怎麼確認API沒有問題呢? 通常再開始真正撰寫前會將頁面圖稿、UI Flow和規格一起對一遍，可以從幾個方向確認規格是否缺漏:

A. 頁面上的資料

這是最直觀可以檢查的，所有頁面上的變動資料，都應該要可以從API中取得。若沒有的話，就可以準備Hello後端我有問題要問你XD

B. 隱藏的資料

雖然畫面上不能直接看到，但是隱藏的資料。
有聽起來超問號嗎XD 來舉個例子吧，比如一個最新消息的詳細頁面，底下有上一則和下一則的按鈕。我們要怎麼知道點了下一則要去哪裡呢?這就是要由API告訴我們下一則的不管是ID或是路徑連結，前端在把上一則或下一則的URL放進超連結中，讓使用者可以順利到達對應的頁面。

C. 隱藏的邏輯

看不到的除了資料，還有邏輯。比如：當使用者點了五次下載後，前端要顯示問卷畫面。使用者點擊下載的次數是由後端紀錄。那當五次到了，需要由後端告知前端，讓前端再將問卷畫面顯示出來。單純看畫面可能會無法直觀地發現，但當想過一遍流程的時候就會注意到了。

畫面上的資料看圖很直觀也是最簡單可以發現，
隱藏的資料和邏輯，除了看圖之外，更重要是要從流程去整個想過一遍比較容易確認喔

確認API是否有缺漏這件事，目的除了如果發現API有缺漏可以趕快跟後端工程師說之外，
也是讓自己在開發前，先看這規格好好的想過一遍再做串接的時候大致上會怎麼做的階段。

03. 確認API是否有真的可以打通

文件、圖稿與FLOW的對應缺漏都對過後，接下來我們要真的來試試看這一堆記錄在文件上的文字能不能用了。這裡就要介紹一個web API測試必備工具Postman（對！就是下圖這個火箭人～～）

• 官方下載點 : 下載連結
• Chrome 擴充版 : 下載連結

(以下圖片取自postman官網)

透過Postman可以實際上測試文件中的API是否都有辦法取得資料。確認API的權限方式、填入URL、Methods、參數等等對應的規格，按下send就可以確認這隻API是不是成功拿到response。或者拿到的response是不是跟文件上寫的一致。

若後端給的API文件是線上整合的類型，如上述的swagger api文件網站，也可以直接用他預設的功能執行API是否能成功取得response，就不用額外再用postman另外設定囉！
這個階段的重點是確認API能順利打通，工具的話也是依照專案中獲得的東西來決定工具，沒有一定只能用postman

從取得API文件、快速確認規格想過一遍流程檢查缺漏、到實際確認每隻API的是不是真實可以執行順利取得response。在開工前的準備大致上就是這樣~
明天我們就要來準備開工串串API~~~