何時使用自定義HTTP 方法

何時使用自定義HTTP 方法

問題描述

您想知道使用自定義HTTP 方法的影響。

解決方案

避免使用非標準的自定義HTTP 方法，因為引入新方法後，就不能依賴那些只瞭解標準HTTP 方法的現有軟體了。

您應該設計一個可以抽象此類操作的控制器（詳見2.6 節）資源，並使用HTTP 的POST方法。

問題討論

擴充套件HTTP 方法最重要的好處是，它可以讓伺服器為擴充套件方法定義清晰的語義並保持介面一致。但是，除非得到廣泛支援，否則擴充套件方法將會降低互操作性。

例如，WebDAV 將MOVE 的語義定義為“邏輯上與複製一致，接著是一致性維護處理，最後進行原始檔的刪除，所有這三個動作是以原子操作的形式來執行的。”任何客戶端都可以透過提交OPTIONS 請求以確認一個WebDAV 資源是否實現了MOVE方法。需要時，如果資源支援MOVE方法，客戶端可以提交MOVE請求把資源從一個地方移動到另一個地方：

# 發現所支援方法的請求

OPTIONS /docs/annual_report HTTP/1.1

Host:

# 響應

HTTP/1.1. 204 No Content

Allow: GET, PUT, DELETE, MOVE

# 移動

MOVE /docs/annual_report HTTP/1.1

Host:

Destination: http:///docs/annual_report_2009

# 響應

HTTP/1.1 201 Created

Location: http:///docs/annual_report_2009

當然也可以遵循WebDAV 的做法，設計一個新方法，比如CLONE，建立一個現有的

資源的副本：

# 克隆請求

CLONE /po/1234 HTTP/1.1

Host:

# 已建立克隆

HTTP/1.1 201 Created

Location: /po/5678

客戶端會發現伺服器支援這一方法，並提交CLONE請求。

實際上，代理、快取及HTTP 庫會將這些方法認定為非冪等、不安全及不可快取的。

換言之，它們對這樣的擴充套件方法使用和POST 一樣的處理規則，POST 也是非冪等、不安全且在大部分情況下是不可快取的。這是因為冪等性和安全性是伺服器必須保證的。對於未知的自定義方法，代理、快取和HTTP 庫不能假定伺服器提供了這樣的保證。因此，對大部分基於HTTP 的軟體和工具，自定義HTTP 方法等同於POST方法。

# 克隆請求

POST /clone-orders HTTP/1.1

Host:

Content-Type: application/x-www-form-urlencoded

id=urn:example:po:1234

# 已建立克隆

HTTP/1.1 201 Created

Location: /po/5678

此外，並不是所有的HTTP 軟體（包括防火牆）都支援任意的擴充套件方法。因此，只有在互操作性不是主要問題時才考慮使用自定義HTTP 方法。

優先使用POST而非自定義HTTP 方法。不是每一個HTTP 軟體都可以讓您使用自定義HTTP 方法的。使用POST是一個更安全的選擇。

本文節選自《RESTful Web Services Cookbook中文版 》一書

圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-708384