API（Application Programming Interface，應用程式介面）可以視為不同軟體系統之間的溝通橋梁，讓雙邊可以交換數據並執行各種功能。這篇會記錄產品經理一定要知道的幾個 API 概念，像是常見的錯誤代碼以及不同的 HTTP 方法（如 PUT、GET、POST）和實際案例說明。
誰適合看這篇文章？
✔ 對產品經理、產品企劃、產品策略、產品規劃有興趣的朋友一、API 基本概念
⠀⠀
1. API 是什麼？
API，即應用程式介面，是一套定義不同軟體應用之間 互動方式 的規則，例如我在電商平台販賣商品，我想將電商平台的訂單拉到自己的網站進行出貨，這時就能直接透過 API 索取資訊，而不需要了解電商平台內部的細節。
⠀⠀
2. 如何使用 API？
使用 API 涉及兩個主要方面：請求（Request）和回應（Response）。當需要從伺服器獲取數據或進行某些操作時，發起者將發送一個「請求」到伺服器，伺服器處理這個請求並返回一個「回應」。
請求（Request）
請求通常包含以下幾個關鍵部分：
- URL：代表 API 的具體資源位置。例如，
https://api.example.com/orders可能是一個獲取訂單的 API URL。 - HTTP 方法：指示伺服器應如何處理該請求。常見的 HTTP 方法包括 GET、POST、PUT、DELETE 等（後面有更多介紹）。
- 標頭（Headers）：附加在請求上的其他資訊，例如商店 ID、消費者 ID 等驗證序號。
- 主體（Body）：一些請求方法（如 POST 和 PUT）可能會包含請求主體，像是若要透過 API 更新資料，就會將要更新的內容填寫在 Body，通常以 JSON 或 XML 格式傳遞。
回應（Response）
回應是伺服器根據請求返回的結果。回應通常包括以下幾個部分：
- 狀態碼（Status Code）：用來指示請求是否成功。常見的狀態碼有：
- 200：成功（OK）
- 400：壞請求（Bad Request），表示客戶端錯誤，如請求格式錯誤。
- 401：未授權（Unauthorized），表示需要身份驗證。
- 404：未找到（Not Found），表示請求的資源不存在。
- 500：內部伺服器錯誤（Internal Server Error），表示伺服器端出現問題。
- 回應主體（Response Body）：通常是 JSON 或 XML 格式的數據，表示伺服器處理請求的結果，像是錯誤原因或獲得的資料。
二、常見 HTTP 方法及其用途
⠀⠀
API 通常會使用不同的 HTTP 方法來進行不同的操作，這些方法代表了對資源的不同處理方式。
1. GET
- 作用：用來從伺服器上獲取資料（例如數據、訂單、商品資訊）。
- 舉例：使用 API 獲取訂單資訊或消費者資訊。
GET https://api.example.com/orders/12345
這個方式可以獲取「訂單ID = 12345」的詳細資訊。2. POST
- 作用：用來向伺服器發送資訊，以建立新的資料（如上架新商品、建立新用戶等）。
- 舉例：使用 API 建立一個新商品。
POST https://api.example.com/product
這個方式可以在對方的平台建立一個商品。
但當然除了 URL 本身，還需要在 Body 填上商品的相關資訊，像是商品名稱、價格。3. PUT
- 作用：用來更新伺服器上的現有資料。相比於 POST 的「建立新資料」，PUT 是「覆蓋舊資料」，意思是將請求中的所有資料都覆蓋上原有資料。
- 舉例：使用 API 更新某個消費者的資訊。
PUT https://api.example.com/customers/12345
這個方式可以將消費者資訊換成正確的姓名、電話、地址等。4. PATCH
- 作用：用來對現有資料進行部分更新。相比於 PUT 的「覆蓋舊資料」，PATCH 是「更新部分資料」，若請求內沒有包含的就不會更新。
- 舉例：更新訂單中的特定項目而不是整個訂單。
PATCH https://api.example.com/customers/12345
這個方式可以只改消費者資訊的姓名，但其他欄位不更新。5. DELETE
- 作用：用來刪除伺服器上的資料。
- 舉例：使用 API 刪除某個消費者資料。
DELETE https://api.example.com/customers/12345
這個方式可以將「消費者ID=12345」的資料進行刪除。
三、常見的錯誤訊息及其處理方式
⠀⠀
在 API 呼叫過程中，有時會遇到錯誤，工作時的口語都會說「API 打不通」。
常見的 HTTP 錯誤代碼可以幫助產品經理更好地溝通問題，並與技術團隊協作解決這些問題，但不同開發團隊使用的代碼都不太一樣，比較常見的像是：
⠀⠀
1. 400 — 壞請求（Bad Request）
這是因為請求格式錯誤或缺少必要的參數所導致的。通常發生在請求的參數、JSON 格式不正確的情況下。
解決方法：檢查請求的 URL、參數和主體，確保它們符合 API 的要求。
2. 401 — 未授權（Unauthorized）
這表示用戶沒有適當的身份驗證、像是沒有 API key，無法訪問資料。
解決方法：確保您已經提供正確的 API 密鑰或身份驗證憑證。
3. 403 — 禁止（Forbidden）
這表示用戶沒有權限訪問所請求的資料，即使身份驗證成功。
解決方法：確認您是否有權限進行該操作，並檢查 API 的權限設置。
4. 404 — 未找到（Not Found）
這表示所請求的資料不存在或 URL 錯誤。
解決方法：檢查請求的 URL，確認資料是否存在以及拼寫是否正確。
5. 500 — 內部伺服器錯誤（Internal Server Error）
這表示伺服器端出現了無法處理的錯誤。
解決方法：通常這種錯誤需要技術團隊來排查伺服器端的問題。
四、實際應用：API 呼叫情境分析
⠀⠀
1. 獲得平台訂單
情境：透過 API 獲取電商平台上的訂單資料，以便了解當月銷售狀況。
- 使用方法：可以用 GET 方法來獲取訂單資訊。通常，打 API URL 時需要提供一個訂單 ID 或某個日期範圍來篩選訂單。
- 發送請求：
GET https://api.example.com/orders?startDate=2023-01-01&endDate=2023-01-31- 處理回應：以上述為例，若只有日期範圍，則對方會回傳指定日期範圍內的所有訂單。
⠀⠀
2. 獲得商品資訊
情境：透過 API 查詢某個商品的詳細資料。
- 使用方法：與獲取訂單類似，也是使用 GET 方法。
- 發送請求：
GET https://api.example.com/product/12345- 處理回應：伺服器返回這個商品的詳細資訊，包括商品名稱、商品特色、商品價格、商品庫存、商品規格等。
⠀⠀
3. 修改商品資訊
情境：透過 API 更新某商品的價格和成本。
- 使用方法：更新整個商品資訊時，使用 PUT 方法進行覆蓋。
- 發送請求：
PUT https://api.example.com/products/67890- 請求主體：
{ "price": 299,
"cost": 100 }- 處理回應：伺服器返回更新後的商品資料，確認修改是否成功。
總結
作為產品經理，API 幾乎是一定會碰到的名詞，特別是 HTTP 方法、常見錯誤代碼。
例如測試產品功能時，有時會需要自己透過 Postman（一個打 API 的小工具 ）去測試 API 的正確與否。
如對這系列文章興趣可以再觀看：
- 如何從 0 到 1 轉職產品經理？從心態準備、求職面試、學習資源拆解｜EP56
- 產品經理要選大公司還是小公司？五種優劣勢一次分析｜EP55
- 產品經理要懂哪些 AI 名詞，以 AI 自傳生成為例｜EP54
非常謝謝你的閱讀！上述單純以我的職場生活來整理，未能涵蓋所有案例。
如果文章有一點啟發或幫助，可以留言或來信讓我知道 👏
．撰寫於：2024/08/03 (六)
