除了最常用的四種方法(GET、POST、PUT、DELETE),HTTP 協議還定義了一些較少使用但非常有用的請求方法,常用于調試、部分更新、跨域預檢等場景。
1. HEAD 方法:獲取響應頭
特點:
- 用途:與
GET
類似,但服務器只返回響應頭,不返回響應體,用于測試資源是否存在 - 作用:用于檢測資源是否存在、是否更新、是否可訪問等
- 冪等性:冪等
- 安全性:安全,不會修改服務器數據
示例:
HEAD /api/articles/10 HTTP/1.1
Host: example.com
用途場景:
- 判斷文件是否存在
- 檢查資源最后更新時間(如
Last-Modified
) - 用于緩存機制優化:節省帶寬
2. OPTIONS 方法:獲取通信選項
特點:
- 用途:查看服務器支持哪些請求方法
- 常用于:跨域請求的預檢(Preflight Request)
- 冪等性:冪等
- 安全性:安全,不影響資源狀態
示例:
OPTIONS /api/articles/10 HTTP/1.1
Host: example.com
典型響應頭:
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
用途場景:
- 跨域訪問時,瀏覽器先發起 OPTIONS 請求確認是否允許實際操作
- RESTful API 開發中用于調試或權限控制
3. PATCH 方法:局部更新資源
特點:
- 用途:對資源進行部分更新
- 與 PUT 的區別:PUT 通常是整體替換,而 PATCH 是局部修改
- 冪等性:通常認為是非冪等的(取決于實現方式)
- 安全性:可能改變服務器資源,需注意權限驗證
示例:
PATCH /api/articles/10 HTTP/1.1
Content-Type: application/json{"title": "Partially Updated Title"
}
用途場景:
- 修改用戶名、昵稱、單個字段信息
- 更節省帶寬,只需傳輸改動部分
4. TRACE 方法:請求回顯(不常用)
特點:
- 用途:用于回顯客戶端發送的請求,主要用于測試和診斷網絡問題
- 不應有請求體
- 冪等性:冪等
- 安全性:不安全,可能造成 XST(跨站追蹤)攻擊,現代瀏覽器通常禁用
示例:
TRACE /api/articles/10 HTTP/1.1
用途場景:
- 已較少使用,主要用于調試底層 HTTP 請求時使用
5. CONNECT 方法:建立隧道連接
特點:
- 用途:用于建立隧道,常用于 HTTPS 的代理傳輸(SSL/TLS)
- 實際用途:客戶端要求代理服務器建立一條 TCP 通道(一般是安全通信)
- 冪等性:非冪等
- 安全性:使用于受控環境中(如代理服務器)
示例:
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
用途場景:
- 瀏覽器通過代理訪問 HTTPS 站點時,發出 CONNECT 請求
- 用于加密隧道傳輸,較底層實現
簡明對比
方法 | 用途 | 是否返回體 | 冪等性 | 是否常用 | 場景 |
---|---|---|---|---|---|
HEAD | 獲取響應頭 | ? | ? | ?(用于優化) | 檢查資源是否存在、是否更新 |
OPTIONS | 探測服務器支持的方法 | ? | ? | ?(用于跨域) | 預檢請求、REST API 功能檢查 |
PATCH | 局部更新資源 | ? | ?/? | ? | 局部修改用戶信息、配置等 |
TRACE | 請求回顯 | ? | ? | ? | 調試 HTTP 請求,現代瀏覽器禁用 |
CONNECT | 建立網絡隧道連接 | ? | ? | ? | 瀏覽器訪問 HTTPS 通過代理 |
實踐建議
-
選擇正確的方法表達語義
- 不要用 POST 做所有事情,PATCH 和 PUT 區分使用
-
合理設計接口
- 用 GET 查詢、POST 創建、PUT 修改、DELETE 刪除,遵循 RESTful API 規范;
-
安全第一
- GET 請求不要放敏感信息(容易被緩存或記錄在日志中)
- TRACE/CONNECT 使用需慎重,避免暴露內部通信
-
配合響應狀態碼
- 不同方法應有合理的返回碼(如 200、201、204、405 等)
理解所有 HTTP 方法,不僅是掌握 Web 開發的基礎,也是構建健壯 API、處理前后端通信問題的關鍵。
在實際開發中,雖然 GET
、POST
占據了大多數使用場景,但 PATCH
、OPTIONS
等方法也具有不可替代的作用,尤其是在現代前端框架和跨域通信中。