昨天我們學會了 RESTful API 的設計原則與 URI 規範。
今天,我們要深入 HTTP 狀態碼,了解如何正確回應客戶端請求,讓 API 更清晰、專業且符合最佳實務。
HTTP 狀態碼是伺服器回應客戶端請求時,附帶的「數字訊號」,用來表示請求結果。
HTTP 狀態碼分為五類:
類別 | 範圍 | 說明 |
---|---|---|
1xx | 100–199 | 信息回應,表示請求已接收,繼續處理 |
2xx | 200–299 | 成功,表示請求成功被伺服器處理 |
3xx | 300–399 | 重導向,表示需要客戶端額外操作 |
4xx | 400–499 | 客戶端錯誤,請求有問題 |
5xx | 500–599 | 伺服器錯誤,伺服器無法完成請求 |
狀態碼 | 說明 | 使用時機 |
---|---|---|
200 OK | 請求成功 | GET、PUT 等成功回應 |
201 Created | 成功建立資源 | POST 新增資源後回應 |
204 No Content | 請求成功但無回應內容 | DELETE 或 PUT 更新成功後無回傳 |
400 Bad Request | 請求格式錯誤 | 客戶端資料缺失或格式錯誤 |
401 Unauthorized | 未授權 | 需要驗證(JWT、API Key) |
403 Forbidden | 禁止存取 | 權限不足 |
404 Not Found | 資源不存在 | 查詢或操作不存在的資源 |
500 Internal Server Error | 伺服器錯誤 | 程式或伺服器異常 |
假設我們有一個「Todo API」:
GET /todos/1
成功回應:
json
HTTP/1.1 200 OK
{
"id": 1,
"title": "學習 RESTful API",
"done": false
}
找不到資源回應:
HTTP/1.1 404 Not Found
{
"error": "Todo 不存在"
}
1.使用正確狀態碼:不要所有錯誤都回 500。
2.清楚的錯誤訊息:讓開發者或前端知道問題所在。
3.統一格式:所有錯誤訊息應遵循同一格式,例如:
{
"code": 404,
"message": "資源不存在",
"timestamp": "2025-09-01T14:00:00Z"
}
4.避免洩漏敏感訊息:伺服器錯誤不要暴露程式堆疊或資料庫訊息。