http的8种请求方法

http方法

8种：GET、HEAD、POST、PUT、DELETE、OPTIONS、TRACE、PATCH
根据RFC2616第九章说明，http方法的定义有两点：safe and Idempotent，即安全性和幂等性，可以结合这两点对以上方法进行说明。

详细说明

GET

特点：安全、幂等。
说明：从服务器端获取数据，请求body在地址栏上。
作用：获取资源。

HEAD

特点：安全、幂等。
说明：与get方法类似，但不返回message body内容，仅仅是获得获取资源的部分信息（content-type、content-length）。
作用：restful框架中较少使用。

POST

特点：非安全、非幂等。
说明：向服务器端提交数据，请求数据在报文body里；
发送一个修改数据的请求，需求数据要重新新创建。
作用：用于创建子资源。创建、更新、删除、查询资源均可使用。

PUT

特点：非安全、幂等。
说明：向服务器端提交数据，请求数据在报文body里；
发送一个修改数据的请求，需求数据更新（全部更新）。
作用：用于创建、更新资源。

DELETE

特点：非安全、幂等。
说明：向服务器端提交数据，请求数据在报文body里；
发送一个删除数据的请求。
作用：删除资源。

OPTIONS

特点：安全、幂等。
作用：用于url验证，验证接口服务是否正常。

TRACE

特点：安全、幂等。
说明：维基百科“回显服务器收到的请求，这样客户端可以看到（如果有）哪一些改变或者添加已经被中间服务器实现。”
作用：restful框架中较少使用。

PATCH

特点：非安全、幂等。
说明：向服务器端提交数据，请求数据在报文body里；
与PUT类似，发送一个修改数据的请求，区别在于PATCH代表部分更新；
后来提出的接口方法，使用时可能去要验证客户端和服务端是否支持；
作用：用于创建、更新资源。局部更新，比如：user对象，只更改了name属性，那么他的其他属性值是不会变的，如果用post，那么其他属性值会被设置为null（全局更新）

幂等性

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。
比如:GET http://www.bank.com/account/123456,不会改变资源的状态，不论调用一次还是N次都没有副作用。
请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。
GET http://www.news.com/latestnews这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

HTTP DELETE方法用于删除资源，有副作用,但它应该满足幂等性。比如: DELETE http://www.forum.com/article/4231,
调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子;因此，调用者可以多次调用或刷新页面而不必担心引起错误。

重点来了：比较容易混淆的是HTTP的 POST和PUT。POST和PUT的区别容易被简单地误认为"POST表示创建资源，PUT表示更新资源”;
而实际上,二者均可用于创建资源，更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的:
POST所对应的URI并非创建的资源本身，而是资源的接收者。
比如: POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。
两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI; 所以，POST方法不具备幂等性。
而PUT所对应的URI是要创建或更新的资源本身。
比如: PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。
对同一URI进行多次PUT的副作用和一次PUT是相同的;因比，PUT方法具有幕等性。

在介绍了几种操作的语义和幂等性之后,我们来看看如何通过Web API的形式实现前面所提到的取款功能。
很简单，POST /tickets来实现create_ticket;用PUT /accounts/account_id/ticket_id&amount=xxx来实现idempotent _withdraw。
值得注意的是严格来讲amount参数不应该作为URI的一部分，真正的URI应该是/accounts/account_ id/ticket_id,而amount应该放在请求的body中。
这种模式可以应用于很多场合，比如:论坛网站中防止意外的重复发帖。