Restful架构风格
REST是英文representational state transfer（表象性状态转移），Rest是web服务的一种架构风格；使用HTTP，URI，XML，JSON等广泛流行的标准和协议；轻量级、跨平台、跨语言的架构设计；它是一种设计风格，不是一个标准，是一种思想。Rest式的web服务是一种ROA（The Resource-Oriented Architecture）（面向资源的架构）
Rest架构的主要原则
网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源描述符（URI）
同一个资源具有多种表现形式（XML、JSON等）
对资源的各种操作不会改变资源描述符
所有的操作是无状态的
符合REST原则的架构方式即可被称为RESTful。
为什么会出现Restful
在Restful之前的操作：
http://127.0.0.1/user/query/1 GET 根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete GET/POST 删除用户信息
RESTful用法：
http://127.0.0.1/user/1 GET 根据用户id查询用户数据
http://127.0.0.1/user POST 新增用户
http://127.0.0.1/user PUT 修改用户信息
http://127.0.0.1/user DELETE 删除用户信息
我们可以看到使用Restful之前每次请求的接口或者地址，都在做描述，如查询的时候用了query，新增的时候用了save，其实完全没有这个必要，我使用了get请求，就是查询，使用了post请求，就是新增的请求，我的意图很明显了，完全没有必要做描述，这就是为什么有了restful。
/*
根据id查询用户
*/
@RequestMapping(value = "/{id}", method = RequestMethod.GET)
public @ResponseBody User list(@PathVariable("id") String id){
Integer sid = Integer.valueOf(id);
System.out.println(sid);
User list = userService.findUserById(sid);
return list;
}
/*
根据id删除用户
*/
@RequestMapping(value="/{id}",method = RequestMethod.DELETE)
public @ResponseBody String deleteUserById(@PathVariable("id") Integer id,@RequestParam(value = "name",required = true) String name){
userService.deleteUserById(id);
return "删除了";
}用POST还是PUT
POST
用于提交请求，可以更新或者创建资源，是非幂等的
举个例子，在我们的支付系统中，一个api的功能是创建收款金额二维码，它和金额相关，每个用户可以有多个二维码，如果连续调用则会创建新的二维码，这个时候就用POST
PUT
用于向指定的URI传送更新资源，是幂等的
还是那个例子，用户的账户二维码只和用户关联，而且是一一对应的关系，此时这个api就可以用PUT，因为每次调用它，都将刷新用户账户二维码
比如一个接口用于用户生成，接收的数据是用户名、密码等相关信息，则用POST
RESTful建议所有的URI都是对应资源，所以创建用户不应该理解为一个行为，在此将此接口命名为:
/user/creation
每次调用它都会新建一个用户（假定用户名可以重复）
而PUT方法更加关心一个具体资源对应的URI，比如更新当前用户信息，这里可以用PUT
/user/me/update
这里用me来指代当前用户，如果是针对更多用户适用的接口，可以考虑
/user/{uid}/update
注意多次调用同一接口，只要提交的数据一致，用户信息每次结果就会一致，即产生同样的结果：服务器端某个具体的资源得到了更新
当需要以更新的形式来修改某一具体资源的时候，如何判断用PUT还是POST呢？
很简单，如果该更新对应的URI多次调用的结果一致，则PUT
比如更新某个blog文章，因为该文章具有单一的具体URI，所以每次更新提交相同的内容，结果都一致
/blog/{document_id}/update
在每次更新提交相同的内容，最终的结果不一致的时候，用POST
举个很常见的例子，一个接口的功能是将当前余额减一个值，每次提交指定该值为100，接口如下
/amount/deduction
调用一次，你的余额-100，调用两次，余额-200
这个时候就用POST
GET
- 安全且幂等
- 获取表示
- 变更时获取表示（缓存）
- 200（OK） - 表示已在响应中发出
- 204（无内容） - 资源有空表示
- 301（Moved Permanently） - 资源的URI已被更新
- 303（See Other） - 其他（如，负载均衡）
- 304（not modified）- 资源未更改（缓存）
- 400 （bad request）- 指代坏请求（如，参数错误）
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务端当前无法处理请求
POST
- 不安全且不幂等
- 使用服务端管理的（自动产生）的实例号创建资源
- 创建子资源
- 部分更新资源
- 如果没有被修改，则不过更新资源（乐观锁）
- 200（OK）- 如果现有资源已被更改
- 201（created）- 如果新资源被创建
- 202（accepted）- 已接受处理请求但尚未完成（异步处理）
- 301（Moved Permanently）- 资源的URI被更新
- 303（See Other）- 其他（如，负载均衡）
- 400（bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 409 （conflict）- 通用冲突
- 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
- 415 （unsupported media type）- 接受到的表示不受支持
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务当前无法处理请求
PUT
- 不安全但幂等
- 用客户端管理的实例号创建一个资源
- 通过替换的方式更新资源
- 如果未被修改，则更新资源（乐观锁）
- 200 （OK）- 如果已存在资源被更改
- 201 （created）- 如果新资源被创建
- 301（Moved Permanently）- 资源的URI已更改
- 303 （See Other）- 其他（如，负载均衡）
- 400 （bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 409 （conflict）- 通用冲突
- 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
- 415 （unsupported media type）- 接受到的表示不受支持
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务当前无法处理请求
DELETE
- 不安全但幂等
- 删除资源
- 200 （OK）- 资源已被删除
- 301 （Moved Permanently）- 资源的URI已更改
- 303 （See Other）- 其他，如负载均衡
- 400 （bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 409 （conflict）- 通用冲突
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务端当前无法处理请求
参考：https://blog.csdn.net/chenxiaochan/article/details/73716617
参考：https://www.runoob.com/w3cnote/restful-architecture.html
参考：https://www.cnblogs.com/kungfupanda/p/5525675.html