在上一篇文章中，我們對 API 有了初步了解，並探討了它作為應用程式間溝通橋樑的角色。今天，我們將進一步深入介紹 Web API，尤其是它如何運作在現代網路應用程式中。同時，我們會詳細解釋 HTTP 協議，因為它是 Web API 交流的基礎。我們將討論 HTTP 的請求方法、結構，以及它如何回傳響應。
什麼是 Web API？
Web API 是一種 API，專門用於網路上的應用程式之間進行數據交換和操作。就像我們之前提到的，API 是應用程式之間的「溝通橋樑」，而 Web API 就是這種溝通的網路版。不同的應用程式可以透過 Web API 共享功能或數據，而無需直接整合彼此的程式碼。
Web API 是基於 HTTP 協議 來進行通信的，這就像網頁伺服器和瀏覽器之間的「語言」。每當你打開一個網站時，背後其實是 HTTP 協議在傳遞請求和回應，而 Web API 也同樣透過這個協議來實現應用程式之間的互動。
HTTP 協議：Web API 的基石
HTTP（Hypertext Transfer Protocol，超文本傳輸協議）是 Web API 最常用的通訊協議。它定義了如何在客戶端和伺服器之間傳遞數據。每一次請求和回應都依賴於 HTTP 協議，它告訴我們該如何發出請求、數據該如何被傳遞，以及伺服器該如何回應這些請求。讓我們看看一些常見的 HTTP 請求方法。
常見的 HTTP 請求方法
- GET：
- 用來從伺服器獲取資源。例如，當你瀏覽網頁或查詢數據時，通常會發送 GET 請求。
- 範例：GET /api/users/123 用來獲取 ID 為 123 的用戶資料。
- 特點：GET 請求是「安全」的操作，它不會改變伺服器上的資源，只是用來讀取數據。
- POST：
- 用來創建新的資源。例如，當你提交表單或上傳數據時，會使用 POST。
- 範例：POST /api/users 用來新增一位新的用戶。
- 特點：POST 會改變伺服器上的數據，並且通常會返回新創建的資源信息。
- PUT：
- 用來更新資源。這通常用來替換現有的數據，適合完整更新。
- 範例：PUT /api/users/123 更新 ID 為 123 的用戶資料。
- 特點：PUT 是冪等的，無論執行多少次，結果都一樣。
- PATCH：
- 用來部分更新資源。例如，你只想更新用戶的名字，而不改動其他資料。
- 範例：PATCH /api/users/123 只更新 ID 為 123 的用戶部分資料。
- 特點：只修改必要的部分數據，不會整體替換。
- DELETE：
- 用來刪除資源。當你想要移除伺服器上的數據時，會使用 DELETE。
- 範例：DELETE /api/users/123 刪除 ID 為 123 的用戶資料。
- 特點：DELETE 請求會永久刪除資源。
這些方法為 Web API 定義了與伺服器互動的方式，每種請求方法對應不同的操作，具體執行邏輯由伺服器決定。
以下是 HTTP 請求方法的整理表格，可以更直觀地瞭解每種方法的用途、特點，以及它們對伺服器資源的影響和安全性：
HTTP 方法用途範例特點對資源的影響安全性
GET
從伺服器獲取資源
GET /api/users/123
請求用來讀取數據，不會改變伺服器上的資源
不改變
安全、冪等
POST
創建新的資源
POST /api/users
用來創建新資源，通常會返回創建的資源信息
改變資源
非安全、非冪等
PUT
完整更新資源
PUT /api/users/123
用來替換現有資源的全部內容
完整替換
非安全、冪等
PATCH
部分更新資源
PATCH /api/users/123
用來部分更新現有資源
部分修改
非安全、非冪等
DELETE
刪除資源
DELETE /api/users/123
用來刪除資源，會永久刪除伺服器上的數據
刪除資源
非安全、冪等
說明：
- 安全性：GET 請求被認為是「安全」的，因為它們不會改變伺服器上的數據。而 POST、PUT、PATCH 和 DELETE 會改變伺服器狀態，因此被視為「非安全」的。
- 冪等：PUT 和 DELETE 被稱為「冪等」的操作，意思是無論你執行多少次操作，結果都是一樣的。而 POST 和 PATCH 是「非冪等」的，因為每次執行可能會導致不同的結果（例如重複創建資源）。
HTTP 的結構：Headers、Body 和狀態碼
HTTP Headers
HTTP Headers 是請求和回應中的元數據，用於傳遞關於請求和響應的額外信息。常見的 HTTP Headers 包括：
- Content-Type：指定請求或回應的數據格式，如
application/json或text/html。 - Authorization：用來傳遞身份驗證信息（例如 Token）。
- Accept：告訴伺服器客戶端希望接收的數據格式。
- User-Agent：識別發送請求的客戶端軟件。
HTTP Body
HTTP Body 是用來傳遞具體數據的部分。對於 POST、PUT、PATCH 這類操作，請求的 Body 通常包含了用來創建或更新資源的數據。而響應的 Body 則通常包含伺服器返回的資源數據。
HTTP 狀態碼
每次伺服器處理完請求後，會返回一個狀態碼，告訴客戶端請求的結果。這些狀態碼幫助我們快速了解伺服器的回應狀況。狀態碼分為五大類：
- 1xx 信息回應：表示請求已接收，正在處理中。
- 2xx 成功回應：表示請求成功處理，最常見的是
200 OK。 - 3xx 重定向：表示資源已移動，需要重定向，常見的是
301 Moved Permanently。 - 4xx 客戶端錯誤：表示請求有問題，例如
404 Not Found。 - 5xx 伺服器錯誤：表示伺服器在處理請求時發生錯誤，如
500 Internal Server Error。
常見的 HTTP 狀態碼一覽表
狀態碼描述類型說明
200
OK
成功
請求成功並返回數據。
201
Created
成功
新資源已成功創建。
204
No Content
成功
請求成功，但無需返回內容。
301
Moved Permanently
重定向
資源已永久移動到新位置。
302
Found
重定向
資源臨時移動。
304
Not Modified
重定向
資源未修改，可使用緩存。
400
Bad Request
客戶端錯誤
請求格式有誤，伺服器無法理解。
401
Unauthorized
客戶端錯誤
請求需要身份驗證。
403
Forbidden
客戶端錯誤
用戶無權進行此操作。
404
Not Found
客戶端錯誤
找不到請求的資源。
500
Internal Server Error
伺服器錯誤
伺服器處理請求時發生錯誤。
502
Bad Gateway
伺服器錯誤
伺服器作為代理，收到無效的上游響應。
503
Service Unavailable
伺服器錯誤
伺服器暫時無法處理請求。
這邊最最最常看到就是那萬惡的404Not Found，就是基於Http協議的狀態碼！
總結：Web API 與 HTTP 的核心聯繫
Web API 的運作離不開 HTTP 協議。無論是發送請求還是接收回應，HTTP 協議中的方法、Headers、Body 和狀態碼，都是讓 Web API 正常運作的基礎。掌握這些概念後，我們就能更好地理解如何設計和使用 Web API。
在下一篇文章中，我們將探討如何設計優秀的 Web API，讓它不僅能運作流暢，還能符合最佳實踐，讓開發者和使用者都獲得良好的體驗。
