何时使用自定义HTTP 方法
问题描述
您想知道使用自定义HTTP
方法的影响。
解决方案
避免使用非标准的自定义HTTP
方法，因为引入新方法后，就不能依赖那些只了解标准HTTP 方法的现有软件了。
您应该设计一个可以抽象此类操作的控制器（详见2.6 节）资源，并使用HTTP 的POST方法。
问题讨论
扩展HTTP 方法最重要的好处是，它可以让服务器为扩展方法定义清晰的语义并保持接口一致。但是，除非得到广泛支持，否则扩展方法将会降低互操作性。
例如，WebDAV 将MOVE 的语义定义为“逻辑上与复制一致，接着是一致性维护处理，最后进行源文件的删除，所有这三个动作是以原子操作的形式来执行的。”任何客户端都可以通过提交OPTIONS 请求以确认一个WebDAV 资源是否实现了MOVE方法。需要时，如果资源支持MOVE方法，客户端可以提交MOVE请求把资源从一个地方移动到另一个地方：
# 发现所支持方法的请求
OPTIONS /docs/annual_report HTTP/1.1
Host: www.example.org
# 响应
HTTP/1.1. 204 No Content
Allow: GET, PUT, DELETE, MOVE
# 移动
MOVE /docs/annual_report HTTP/1.1
Host: www.example.org
Destination:
http://www.example.org/docs/annual_report_2009
# 响应
HTTP/1.1 201 Created
Location:
http://www.example.org/docs/annual_report_2009
当然也可以遵循WebDAV 的做法，设计一个新方法，比如CLONE，创建一个现有的
资源的副本：
# 克隆请求
CLONE /po/1234 HTTP/1.1
Host: www.example.org
# 已创建克隆
HTTP/1.1 201 Created
Location: www.example.org/po/5678
客户端会发现服务器支持这一方法，并提交CLONE请求。
实际上，代理、缓存及HTTP
库会将这些方法认定为非幂等、不安全及不可缓存的。
换言之，它们对这样的扩展方法使用和POST 一样的处理规则，POST 也是非幂等、不安全且在大部分情况下是不可缓存的。这是因为幂等性和安全性是服务器必须保证的。对于未知的自定义方法，代理、缓存和HTTP 库不能假定服务器提供了这样的保证。因此，对大部分基于HTTP 的软件和工具，自定义HTTP 方法等同于POST方法。
# 克隆请求
POST /clone-orders HTTP/1.1
Host: www.example.org
Content-Type:
application/x-www-form-urlencoded
id=urn:example:po:1234
# 已创建克隆
HTTP/1.1 201 Created
Location: www.example.org/po/5678
此外，并不是所有的HTTP
软件（包括防火墙）都支持任意的扩展方法。因此，只有在互操作性不是主要问题时才考虑使用自定义HTTP 方法。
优先使用POST而非自定义HTTP 方法。不是每一个HTTP 软件都可以让您使用自定义HTTP
方法的。使用POST是一个更安全的选择。
本文节选自《RESTful Web Services Cookbook中文版 》一书
图书详细信息:http://www.cnblogs.com/broadview/archive/2011/09/27/2193380.html