在最近的面试中，有问到说是说一下 RESTful API 的几个方法。
这次面试问的问题还是比较多的，但是很多问题都是开放性问题，说心里话很长时间没有遇到这样比较好的沟通式面试了。
不少公司，以上来就做题目，这个让人很反感。
不过现在做题目的过程中，很多公司也都强调，我们不需要有完整的方案，不能运行也没有关系，主要是看思路吧。
小结
这个问题是完全的开放式问题，如果你的公司不完全按照 RESTful 的设计来的话，可能大概率会用到 POST， 和 GET。
因为上面的这个 2 个方法是最常用的。
我的回答是：这个和项目有关，有些项目在设计的时候为了不对方法进行过多约束，会全部要求使用 POST，哪怕是请求资源也是要求 POST 的。
那么如果使用 POST 我们如何进行删除，这个通常会在请求的 JSON 数据块中添加一个 Action 的字段，在这个字段我们告诉后端程序这次调用我们是干什么用了。
后续问题 PUT
在聊了上面的问题后，又问了一个后续的问题，PUT 和 PATCH 的区别是什么呀？
这个还真有点把我给问到了。
我们很多项目真正用到 PUT 和 PATH 的情况不多，大部分情况都是 POST 给代劳了。
既然问到了，那么就有必要脑补下相关 RESTful API 用的几个方法了。
RESTful 的 5 个方法
在 RESTful 中，我们定义了 5 个方法。
- GET：读取（Read）
- POST：新建（Create）
- PUT：更新（Update）
- PATCH：更新（Update），通常是部分更新
- DELETE：删除（Delete）
对获取资源，我们通常是 Get，就好像和网页进行交互的时候，我们访问一个网站，其实对应的很多时候都是 GET 请求，把我们需要的资源请求过来。
POST 通常用于和服务器进行交互，包括数据的添加，查询，修改等等，其实都可以用 POST 来完成的。
DELETE 方法，这个方法用于从服务器上删除数据用的。很多人以为从服务器上删除数据后，服务器会把数据真实进行删除。在一般的数据量不是非常大的应用系统中，我们的设计大部分是打上一个删除标记，数据不显示，但是数据还是真实存在的。
因此删除的方法是可以用 POST 来解决的，DELETE，在 API 的设计中就没有 POST 和 GET 常见了。
PUT 方法：PUT 方法就是更新了。这个地方应该定义为全对象更新，比如说用户对象，我们有很多属性，如果你使用 PUT 对象的话，就会把用户对象中的所有属性全部更新掉。
PATCH 方法：这个是 PUT 更新方法的进阶版本。假设你还是要更新一个用户数据，这个时候你不需要把所有的用户数据全部上传上来。比如说只更新用户的地址这一条记录，你可以直接只在方法中上传用户地址信息，服务器就只更新地址。
PUT 方法的实体无结构的，它直接把实体部分的数据替换到服务器的资源上。
而 PATCH 提供的实体则需要根据程序或其它协议的定义，解析后在服务器上执行，以此来修改服务器上的数据。也就是说，PATCH请求是会执行某个程序的，如果重复提交，程序可能执行多次，对服务器上的资源就可能造成额外的影响，这就可以解释它为什么是不幂等的了。
假设我们有一个UserInfo，里面有userId， userName， userGender等10个字段。可你的编辑功能因为需求，在某个特别的页面里只能修改userName，这时候的更新怎么做？
人们通常(为徒省事)把一个包含了修改后userName的完整userInfo对象传给后端，做完整更新。但仔细想想，这种做法感觉有点二，而且真心浪费带宽，从现在的技术角度来说，带宽的问题通常考虑得不是非常多了。
更主要的是安全相关吧，本来你只需要更新一个用户名的，结果用 PUT 把整个用户对象的数上传上去了，等于在网络上传递了一些没有用的信息，这可能会存在一定的泄露风险。
于是patch诞生，只传一个userName到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。
而put虽然也是更新资源，但要求前端提供的一定是一个完整的资源对象，理论上说，如果你用了put，但却没有提供完整的UserInfo，那么缺了的那些字段应该被清空。
实际情况
在实际上，我们更新很多时候也会使用 POST 方法。
例如上面说的只更新地址信息，实际上服务器的操作还是根据你上传的用户 ID 到数据库中查询用户信息，然后返回用户对象。
下一步就是对你上传的数据进行校验，对提交的更新字段进行更新，对没有提交的更新字段进行忽略。
所以 PUT 和 PATCH 是可以通过 POST 方法来实现的，而且很多情况我们也会用 POST 方法来实现。
