今日主題

所謂的授權(Authorization)指的是根據發出請求者的身分來檢查是否擁有權限進行當前操作，API透過這樣的保護機制來避免權限過於開放而被濫用。常會聽到驗證(Authentication)被拿來與之比較，一說是驗證為過程，驗證使用者的身分，而授權則是在確認身分之後，檢查該使用者是否擁有權限。以Http狀態碼來對照的話，如果沒通過驗證會是401 Unauthorized，通常就是還沒登入的狀況，而已經登入後卻沒有權限，這時的狀態碼就會是403 Forbidden，表示伺服器理解了該請求但不給予授權。

通常如果我們自己開發API，也會需要提供授權機制，而使用第三方提供的API的話，就需要按照提供服務者的規範了，例如今天會使用到的Postman API，這套API就是官方提供給Postman使用者們可以用很簡單的方式去存取與帳號相關的資料，所以這些API就會需要有授權機制，在使用者使用這些API時搭配每個人專屬的金鑰，才能正確去取用資料，換言之其他人沒有我的金鑰，就無法存取到我的私人資料。

那麼在開始之前，請別忘了將今天的挑戰Day 4: Authorization先行fork到自己的工作區喔。

另外，由於今天挑戰的文件有提到會需要使用到Postman API，所以也要到這裡將Postman API整個Collection都fork回自己的工作區，如下圖:

接下來會依序新增三個Request，用不同的方式來體驗如何提供API Key

• 新增請求一 (header)
  到自己工作區剛剛複製過來的Postman API這個Collection，找到Get all collections這個請求，將他拖曳到今天挑戰的Authorization資料夾下，並重新命名為All Collections - header，切到Header編輯頁面新增一組x-api-key與對應的值{{postman_api_key}}，如下圖

  

  這個做法就是透過手動編輯Header的方式將x-api-key的值向API表明發送者的身分，要特別注意的是這邊因為用的是變數，記得選定好先前編輯好的Environment，或是自行再編輯變數才可以。最後按下Send來確認是否能得到200狀態碼。

• 新增請求二 (query params)
  複製剛剛第一個步驟設定好的請求，然後重新命名為All Collections - query params，然後移除Header裡面剛新增的x-api-key，因為這個新請求不透過新增Header的方式了，我們要切換到Params頁面新增apikey以及其值{{postman_api_key}}，新增完也會看到URL同步發生了變化，如下圖

  

  接著Send，拿到200，打完收工。看到這邊，可能會有個疑惑，GET裡面放機敏資料這樣真的好嗎，有興趣的話可以看看這篇延伸閱讀

• 新增請求三 (auth helper)
  一樣也是透過複製上一個請求，然後移除Params剛剛所新增的內容，然後將新的請求重新命名成All Collections - auth helper。接著到Authorization這個資料夾下，選擇type為API Key，下方基本跟前面加Header一樣，如下圖

  

  這樣就能讓同個資料夾下所有的請求都能透過auth helper自動往Header添加x-api-key，也就是說前面的兩個請求所手動加入的金鑰都移除還是能正常使用，可以試試看移除後都各自Send，如果都還能得到200就表示auth helper設定成功了。

  新增auth helper後，可以去各個請求的Header看看hidden裡是否有被自動加入的x-api-key?

最後，submit的方式跟前幾天的方式都一樣，可以確認是否有測項沒有通過，都通過就表示今天挑戰成功!

今日回顧

今天我們體驗了不同的方式讓API能給予授權，但除了API Key之外，還有其他不同的方式如Bearer Token，OAuth，有機會的話會開篇章特別介紹這些內容的。

• Postman API
• Authorizing requests