前言
REST，即“表现层状态转移”，它确立了互联网软件服务的架构规则。若一个架构契合REST的相关原则，便被称作RESTful架构，这是当下流行的互联网软件服务架构设计风格之一。
要知道，REST并非是一种标准，更像是一种架构理念与设计准则，其目的在于让Web API更为简洁、便于理解和使用。
在开发过程中，后端常常需要向客户端提供API接口以供使用，所以在设计API接口时，要尽量让客户端能够快速明白API的含义。要是遵循一定规范来设计，就能极大地减少前后端沟通的成本，提高开发效率。
一、RESTful的特点
RESTful主要有以下几个特性：
1、同一资源使用同一个URI
2、接口规范统一☆
3、同一资源具备多样表现形式（json/html）
4、客户端与服务端的请求交互是无状态的
5、支持缓存（允许客户端缓存响应内容）
无状态特性
HTTP请求自身是无状态的，它基于client - server架构。每一个从客户端发往服务器的请求都必须包含所有必要信息，这样服务器才能理解请求并独立处理它。这意味着服务器不会存储任何会话信息，无法从当前请求中获取之前请求的任何内容。
规范统一接口
我们先举个简单例子。
比如传统开发中实现一个删除功能，其路径可能是这样的：
GET http://localhost:8080/delete?id=20
而采用RESTful设计风格的路径则是这样的：
http://localhost:8080/users/20
是不是看着清爽很多呢？传统方式针对同一资源进行增删查改可能需要四个不同的接口，维护起来不太方便。RESTful的主要特点是通过资源进行分组，同一组别的系统组件之间的交互通过统一接口来进行。
比如针对用户的操作都由users这个URI（统一资源标识符）来标识，获取、创建、更新、删除都通过统一路径来访问。那么服务端该如何区分不同操作呢？
通过规定使用标准的HTTP方法来执行操作，常见的方法有：
- GET ：用于获取资源。
- POST ：用于创建新资源。
- PUT ：用于更新现有资源。
- DELETE ：用于删除资源。
- PATCH ：用于对资源进行部分修改。
也就是说，采用RESTful规范后，针对统一资源操作的API就只剩下一个了。执行增删查改操作时，只需使用不同的请求类型（HTTP Method）就行。并且服务端返回的数据也能够完全一致，前端可以通过不同的HTTP状态码来判断请求是否成功。
二、Spring中实现RESTful API
Spring Boot对RESTful API提供了支持。主要通过与REST操作方式对应的注解来实现：
- @GetMapping：处理GET请求，获取资源
- @PostMapping：处理POST请求，新增资源
- @PutMapping：处理PUT请求，更新资源
- @DeleteMapping：处理DELETE请求，删除资源
- @PatchMapping：处理PATCH请求，用于更新部分资源
在RESTful规范中，每个网址对应一个资源，所以给URI命名时尽量采用名词，而且一般与数据库的表名相对应。
比如用户管理模块的API就可以这样设定：
对应的Spring Boot代码如下：
@RestController
@RequestMapping("/user")
public class UserController {
//根据id获取用户信息
@GetMapping("/{id}")
public Result get(@RequestParam Integer id){
//业务逻辑
return Result.success();
}
//添加用户
@PostMapping
public Result add(@RequestBody User user){
//业务逻辑
return Result.success();
}
//修改用户信息
@PutMapping
public Result update(@RequestBody User user){
//业务逻辑
return Result.success();
}
//修改用户的某个参数，如密码、头像等
@PatchMapping("/password")
public Result updateAvatar(@RequestParam String password){
//业务逻辑
return Result.success();
}
//根据id删除用户
@DeleteMapping("/{id}")
public Result delete(@RequestParam Integer id){
//业务逻辑
return Result.success();
}
}
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/12638.html
