API

網址是 API 的門面，大家使用 API 的第一步就是要看它，所以第一眼就要讓人就知道這隻 API 在做什麼？ 甚至因為遵循標準（目前 REST 是主流），可以類推 API 應該會有什麼功能等等。 網址規劃的好，未來隨著需求變化也比較有彈性能夠修改 / 擴充。 網址設定跟著這些原則走，輕鬆沒煩惱 1. 命名簡單明瞭 https://api.test.com/products/ 1234 這個網址代表是一個 api 的位置，這會取得編號 1234 的商品資料 (products) 2. 不要使用過度簡化的單詞 https://api.test.com/ p /666 這邊 p 代表是 products 嗎？還是 plan ? 3. 以小寫英文為主 因為有些系統會識別大小寫英文（代表不同的東西：例如： Products vs. products 視為不同） 另外，國際主流語言還是以英文為主（畢竟電腦也是美國發明的～） 4. 避免使用自定義名詞 https://api.test.com/free_choice/555 餐餐自由選？ https://api.test.com/tuango/888 團購商品？ 5. 使用複數名詞命名 這個牽涉到 REST 的設計原則：如果沒有帶識別詞（例如：編號）就等同於取得列表 https://api.test.com/products 取得商品列表（一坨商品） https://api.test.com/products/1234 取得編號 1234 的商品資料（一個商品）...

隨著各種行動裝置與各式各樣的載體出現，API 讓前後端程式開發人員能夠更快速串接新功能，又能夠在不同裝置上帶給使用者不一樣的體驗。每每當程式要上線前，總是讓開發人員既期待又怕受傷害，一方面是辛辛苦苦的孩子終於要出世了，一方面又會怕會不會有新的 BUG 出現（我養 BUG，BUG 養我） 這時候測試就很重要啦，既能夠保證功能如需求完成，又能保護下次新加功能不會改 A 爛 B。 好的 API 讓前端輕鬆串接，專注呈現各式各樣的體驗；後端只需要專注於保證穩定功能的輸出，大家開開心心 ～ API 沒寫好，輕則資料呈現錯誤，重則 APP 閃退負評滿點… API 測試從這三個地方著手，一定面面到位 1. 功能：是否完成 API 主要的目的 以取得商品資料來說，輸入了商品編號作為查詢必要參數，是否有正確回應商品資料？回應的商品資料格式是否正確？是否支援像是顏色等選填參數？ 如果沒有此商品，API 是否有正確回應找不到商品的錯誤？或者是否有非預期的情況發生？ ⚠️ 測試通常都著重於正確的情況，但錯誤的情況也是很重要，至關使用者體驗與是否能夠透過此方式主動發現問題 另外，選填參數也是常常會忽略的地方，例如：頁數、每頁幾個、日期，這些是否有符合規定？數字是否負數？起始日期是否小於結束日期？ 2.性能：是否能夠"及"時處理完？ 這邊特別強調是及時，因為每隻 API 對於速度的要求不一，是否能夠在容許的請求時間內回應決定在使用情境上。 通常合理的要求回應時間多半低於 500 毫秒 (ms)。 3.安全性：牽涉到需要存取權限的 API 是否有驗證機制？ 多半而言每個人只能夠查詢自己的個人資料，別人必須無法存取。那 API 應該透過什麼方式來實現權限控管？驗證機制會是使用什麼方式？ 延伸說明 API 由三個部分組成 Header 通常包含常用且通用的參數：api-key, token, language … URL (Method) 存取的位置，包含取用的方法：GET, POST, PUT, DELETE … Body...