Laravel POST、PUT、PATCH 路由的区别

第一篇

经常会混淆HTTP的POST/PUT方法，因为这两个方法似乎都可以用来创建或更新一个资源。区别是细微但清楚的：

POST方法用来创建一个子资源，如 /api/users，会在users下面创建一个user，如users/1

POST方法不是幂等的，多次执行，将导致多条相同的用户被创建（users/1，users/2 …而这些用户除了自增长id外有着相同的数据，除非你的系统实现了额外的数据唯一性检查）

而PUT方法用来创建一个URI已知的资源，或对已知资源进行完全替换，比如users/1，
因此PUT方法一般会用来更新一个已知资源，除非在创建前，你完全知道自己要创建的对象的URI。

PATCH方法是新引入的，是对PUT方法的补充，用来对已知资源进行局部更新

GET 获取资源
POST 创建资源
PUT 编辑/更新资源（需提交完整的资源字段）
PATCH 编辑/更新资源（可以提交需要更新的字段）
DELETE 删除资源
OPTIONS 服务器允许哪些请求谓词

这些就是最近比较流行的RestFul模式常用的，另HTML表单只支持POST、GET两种请求方式，PUT、PATCH以及DELETE是Laravel中伪造的HTTP请求方式，需要在表单中添加才能生效，还要配置路由。

常用的请求方法里面GET请求和POST请求我们都非常熟悉了，今天来谈谈POST,PUT以及PATCH，在了解这些之前我们先理解一个概念 幂等性:

第二篇

幂等性：
HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：

一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；
另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。
GET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

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

POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源.但实际上两者都可以用来创建或是更新数据.单从技术上来说,他们并没有什么区别.但是在HTTP规范中POST是非等幂的,多次调用会产生不同的结果,比如:创建一个用户,由于网络原因或是其他原因多创建了几次,那么将会有多个用户被创建.而PUT id/456则会创建一个id为456的用户,多次调用还是会创建的结果是一样的,所以PUT是等幂的.

PATCH一般是用来局部更新资源的,假设我们有一个UserInfo，里面有userId， userName， userGender等10个字段。可你的编辑功能因为需求，在某个特别的页面里只能修改userName，这时候的更新怎么做？

人们通常(为徒省事)把一个包含了修改后userName的完整userInfo对象传给后端，做完整更新。但仔细想想，这种做法感觉有点二，而且真心浪费带宽(纯技术上讲，你不关心带宽那是你土豪)。

于是PATCH诞生，只传一个userName到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。

而PUT虽然也是更新资源，但要求前端提供的一定是一个完整的资源对象，理论上说，如果你用了PUT，但却没有提供完整的UserInfo，那么缺了的那些字段应该被清空.另外PUT会有一个create操作,加入更新的id不存在,会进行创建,而PATCH则没有这个.

第三篇

目前互联网公司的应用架构基本都是前后端分离，后端的接口也基本上都是采用restful架构了，接下来就说说restful的使用。
使用restful架构最主要的是遵循rest的思想：“统一资源接口“。
REST全称：Representational State Transfer，翻译成中文就是“表述性状态转移”，表述的对象就是资源，在web的rertful架构中都是通过uri来一一对应资源，比如：/api/person/1。
URI既可以看成是资源的地址，也可以看成是资源的名称，代表的就是唯一的资源，但是不能表示对资源的操作，操作是结合标准的http方法（get、post、put等）来实现的。

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

1，GET
安全、幂等；
用于获取资源；

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

3，POST
非安全、非幂等；
用于创建子资源

4，PUT
非安全、幂等；
用于创建、更新资源；

5，DELETE
非安全、幂等；
删除资源；

6，OPTIONS
安全、幂等；
用于url验证，验证接口服务是否正常；

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

8，PATCH
非安全、幂等；
用于创建、更新资源，于PUT类似，区别在于PATCH代表部分更新；
后来提出的接口方法，使用时可能去要验证客户端和服务端是否支持；

接下来说一下日常中的使用：
1，post和put的区别：

post和put的区别在于uri，或者说post用于创建子资源，比如接口：POST /api/person/ 会创建一个资源比如 /api/person/1或者/api/person/2 … 或者/api/person/n，创建了新的uri，而put方法创建资源的uri是 PUT /api/person/1，这样就创建了一个资源，如果1已经存在那么就是更新，所以put并不是只是更新操作。再有post是非幂等的。
通常情况下，我们都会将post、get、put、delete对应到CRUD操作上，但实际上put并不是只能更新。

2，patch的使用：
patch是2010后成为的正式http方法，详见RFC5789，它是对put的补充，在没有patch之前，我们都是用put进行更新操作，这时候我们的接口中通常会有一个逻辑规则，如：如果对象的的一个字符属性为NULL，那么就是不更新该属性（字段）值，如果对象的字符属性是“”，那么就更新该属性（字段）的值，通过这种方式来避免全部覆盖的操作。现在有了patch就解决了这种判断，在put接口中不管属性是不是null，都进行更新，在patch接口中就对非null的进行更新；

3，uri的使用问题
上边也介绍过了，uri即使代表资源的，通过不同的方法来区分操作，那么像如下的接口就已经违反了restful规范：
GET /api/getPerson/1
DELETE /api/delPerson/1
GET /api/person/get/1
DELETE /api/person/delete/1
在复合规范的前提下，uri的定义应该也是实际使用中应该考虑的，比如uri包涵那些信息？如版本、资源分类、资源名称、表述格式等，对于设计上的不多说了，直接看下面的url：
/api/1.0/person/man/1.xml
/api/2.0/person/man/1.json
这样的url很常见也很直观，对不同版本接口增加了版本信息，并且对数据的表述格式进行了显式指定，不是不好，但是按照“统一资源接口”的思想，资源的uri已经不唯一了。有说对于版本号，表述形式等可以放到http的accept中进行指定，但具体没有验证过，希望经验人士多多指教！

4，查询问题的讨论：
按照rest建议，查询操作要使用get方法，但是实际情况中处理起来比较麻烦，如：报表统计查询，需要传递的参数很多，就SpingMVC来说，如果采用get方法，那么@RequestParam接收的参数非常多，接口很难看，通常会封装为java对象，希望通过@RqeustBody接收并处理，但这是不支持get方法，所以很蛋疼；
对于这种情况，最简单的方式就是改成post方式，而且很多公司都是这么干的，但又觉得违反了restful规范；不改成post方式的话可能就需要将传递的参数对象细腻转为json串，后端字符串接收后再转为对象，这样感觉耶不太好，url中显式输出参数信息，个别情况json串太长活着包含特殊字符等也都很麻烦。
希望经验人士多多指教！