REST（REpresentational State Transfer），表述性状态转换，它是一种软件架构的风格。这么说可能太过于专业，有些难以理解，不妨看个案例：

传统风格url

假如说我们需要使用传统风格url发起请求，那么将会是这样的：

1.请求方式：GET URL：http://localhost:8080/user/getById?id=1 含义：查询id为1的用户

2.请求方式：POST URL：http://localhost:8080/user/saveUser 含义：新增用户

3.请求方式：Post URL：http://localhost:8080/user/updateUser 含义：修改用户

4.请求方式：GET URL：http://localhost:8080/user/deleteUser?id=1 含义：删除id为1 的用户

这是传统风格url发起请求的方式，看起来好像没有什么问题，假如说只有一个人进行开发，使用传统风格的url确实没有什么大问题，但是假如说一个项目进行联合开发，很多人一起开发，使用传统风格的url就会出现问题：张三写查询的时候，写的请求路径是”selectById“，李四写的是”findById“，王五写的是”findUser“。但是后端程序接收响应的路径只有一个，就会引起报错，说明在联合项目开发中，传统风格url请求难以维护，所以说不推荐。

Restful风格

假如还是进行上述的请求，我们使用Restful风格进学校请求，就可以很好的规避这些问题：

1.请求方式：GET URL：http://localhost:8080/users/1 含义：查询id为1的用户

2.请求方式：DELETE URL：http://localhost:8080/user/1 含义：删除id为1的用户

3.请求方式：POST URL：http://localhost:8080/users 含义：新增用户

4.请求方式：PUT URL：http://localhost:8080/users 含义：修改用户

REST 强调使用统一的接口来与资源进行交互，这个统一接口主要是基于 HTTP 协议定义好的方法来实现的。最常见的就是对应 “增删改查” 操作的 HTTP 方法：

GET：用于获取资源的表示形式，也就是查询操作。比如，你想查看某个用户的信息，就可以发送 GET 请求到 /users/456（假设 456 是用户的唯一标识），服务器收到请求后会返回该用户相关的数据，像用户名、年龄、地址等信息给客户端，这就如同你去图书馆查询某本书的资料，只需要请求书这一类的资源，然后提供书的id，管理员就会把书的相关内容提供给你一样。

POST：通常用于创建新的资源。例如，要在系统中新增一个用户，客户端可以向 /users 发送 POST 请求，同时在请求体中携带新用户的相关信息（如用户名、密码等），服务器接收到请求后会根据这些信息创建一个新的用户记录并存入数据库，就好比你向图书馆捐赠一本书，提供了书的信息，管理员把新书登记入库那样。

PUT：用于更新现有资源。假如刚才创建的那个用户要修改自己的地址信息，客户端就可以发送 PUT 请求到 /users/456，并在请求体中带上更新后的地址信息，服务器收到后会用新的信息替换原来的地址记录，这类似于你发现图书馆某本书的信息有误，提供了修改后的正确信息，告知管理员进行修改更新一样。

DELETE：顾名思义，是用来删除资源的。比如要删除刚才那个用户账号，就可以向 /users/456 发送 DELETE 请求，服务器收到后会将对应的用户记录从数据库中清除，就好像图书馆把一本破旧不再使用的书从馆藏中移除一样。

无需多言，直接看请求的URL就可以发现Restful风格的好处：通过URL定位需要请求的资源，使用Http的请求描述需要进行操作（正好是最常用的增删改查），使用Restful风格的请求更加的简洁、规范、优雅，是现在主流的请求风格。

注意：

1.REST只是风格，是约定的方式，并不是规定，是可以打破的（但是为了开发的规范，不要打破）。

2.描述功能模块通常使用复数形式（加s），表示这一类的资源，而并非是单个资源。如：users表示请求的是User这一类的资源，books表示请求的是Book这一类的资源。