產品經理一定要知道的 API 知識｜EP57

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