何时使用自定义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://blog.chinaunix.net/space.php?uid=13164110&do=blog&id=2920780