RESTful, 说说 http 的 patch method

最早的时候，我们只需要 GET 和 POST 方法，POST 方法的引入也只是为了消除 URL 过长，参数隐藏，上传文件的问题，完全和语义无关。接触到 RESTful 之后，我们开始思考 GET 和 POST 的不同语义，并且十分必要的去发掘出所有的 HTTP method，HTTP/1.1 所实现的 method，见 RFC 2616, 有这些：

OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT

规范是这么定义的，这还要看容器实现了多少，比如 Tomcat 7 中的 servlet api 实现了

doOptions, doGet, doHead, doPost, doPut, doDelete, doTrace 就差个 doConnect 了。

而我们这里要说的 PATCH method 是在 Servlet 3.0 和当前 Tomcat 7 中都提到的，也就是尚未实现它。

这也难怪，PATCH 在 2010 年三月份才成为正式的方法，见 RFC 5789。没有 PATCH 的时候我们进行更新的操作采用的是 PUT 方法。那么 PATCH 和 PUT 有什么区别呢？

同样可以从语义上去理解，有两方面的对比：

1. 对已有资源的操作：

PATCH 用于资源的部分内容的更新，例如更新某一个字段。具体比如说只更新用户信息的电话号码字段

而 PUT 用于更新某个资源较完整的内容，比如说用户要重填完整表单更新所有信息，后台处理更新时可能只是保留内部记录 ID 不变。

2. 当资源不存在时：

联想到版本控制 PATCH 是修改原来的内容，也可能会产生一个新的版本。比如当资源不存在的时候，PATCH 可能会去创建一个新的资源，这个意义上像是 saveOrUpdate 操作。

PUT 只对已有资源进行更新操作，所以是 update 操作

见 When should we use the PATCH HTTP method? in The RESTful CookBook

The HTTP methods PATCH can be used to update partial resources. For instance, when you only need to update one field of the resource, PUTting a complete resource representation might be cumbersome and utilizes more bandwidth

PATCH /user/jthijssen HTTP/1.1
<user>
    <firstname>Joshua</firstname>
</user>

Also, the PUT method is idempotent. PUTting the same data multiple times to the same resource, should not result in different resources, while POSTing to the same resource can result creation of multiple resources.

- See more at: http://restcookbook.com/HTTP%20Methods/patch/#sthash.gYGM7j3Q.dpuf

在 RFC 5789 更详述了 PATCH 与 PUT 的区别。

再来看下目前谁实现了 PATCH 方法，谁还没有实现 PATCH 方法

1. Apache HttpComponents HttpClient version 4.2 or later 支持了 PATCH
2. 目前 JDK7 的 HttpURLConnection 未实现 PATCH
3. TOMCAT 7 也不行
4. PlayFramework 2 也不支持
5. Spring 3.2 开始支持 PATCH 方法，但要选对部署的容器
6. JBoss Netty 支持 PATCH，可见： http://docs.jboss.org/netty/3.2/api/org/jboss/netty/handler/codec/http/class-use/HttpMethod.html

总之现在实现了 PATCH 方法的容器真是少。

参考：1. List of HTTP methods (verbs)
             2. Method Definitions
             3. RFC 5789 - PATCH Method for HTTP
             4. RFC 2616
             5. Standard Methods- RESTful API Design