When to use the custom HTTP Method

When to use the custom HTTP Method

Problem description

You want to know the impact of using custom HTTP methods.

Solution

Avoid using non-standard custom HTTP methods, because after the new method is introduced, you cannot rely on existing software that only understands the standard HTTP method.

You should design a controller that can abstract such operations (see section 2.6) and use the http post method.

Problem Discussion

The most important advantage of HTTP method extension is that it allows the server to define clear semantics for the Extension Method and maintain interface consistency. However, unless widely supported, the extension method will reduce interoperability.

For example, WebDAV defines the semantics of move as "logically consistent with replication, followed by Consistency Maintenance, and finally deletes the source file, all three actions are performed in the form of atomic operations." Any client can submit an options request to check whether a WebDAV resource has implemented the move method. If the resource supports the move method, the client can submit a move request to move the resource from one place to another:

# Discovering requests for supported Methods

Options/docs/annual_report HTTP/1.1

HOST: www.example.org

# Response

HTTP/1.1. 204 NO content

Allow: Get, put, delete, move

# Mobile

Move/docs/annual_report HTTP/1.1

HOST: www.example.org

Destination: http://www.example.org/docs/annual_report_2009

# Response

HTTP/1.1 201 created

Location: http://www.example.org/docs/annual_report_2009

Of course, you can also follow the WebDAV approach to design a new method, such as clone, to create an existing

Resource copy:

# Clone request

Clone/po/1234 HTTP/1.1

HOST: www.example.org

# Clone created

HTTP/1.1 201 created

Location: www.example.org/po/5678

The client finds that the server supports this method and submits a clone request.

In fact, the proxy, cache, and HTTP database determine these methods as non-idempotent, insecure, and non-cacheable.

In other words, they use the same processing rules as post for such extension methods. Post is also non-idempotent, insecure, and cannot be cached in most cases. This is because idempotence and security must be ensured by the server. For unknown custom methods, the proxy, cache, and HTTP library cannot be assumed that the server provides such a guarantee. Therefore, for most HTTP-based software and tools, custom HTTP methods are equivalent to post methods.

# Clone request

Post/clone-orders HTTP/1.1

HOST: www.example.org

Content-Type: Application/X-WWW-form-urlencoded

Id = urn: Example: Po: 1234

# Clone created

HTTP/1.1 201 created

Location: www.example.org/po/5678

In addition, not all HTTP software (including firewalls) support arbitrary extension methods. Therefore, custom HTTP methods are considered only when interoperability is not a major issue.

The post method is preferred instead of the custom HTTP method. Not every HTTP software allows you to use custom HTTP methods. Using post is a safer choice.

 

This article is excerpted from the book restful Web Services cookbook Chinese version.

Book details: http://blog.csdn.net/broadview2006/article/details/6826999