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