前后端请求一致性学习
在进行前后端分离开发项目的过程中，前后端同学往往需要依照接口文档的基本信息以及相应的响应格式进行接口请求的开发，在这个过程中涉及到常见的Get、Post、Put、Patch等等的请求，相应的前后端的书写格式是什么，这篇文章进行一个记录学习
一、GET请求
前端发送特点： get请求通常用于客户端向服务器获取数据，其参数携带在请求的URL地址上
后端接收特点：通过GetMapper(‘url’) + @RequsetParam 或 @PathVariable 进行接收
具体的：
| 接收方式 | 适用情况 | 特点 |
| GetMapper + @RequsetParam | 前端请求路径为：/category/detail ？{参数} | 参数拼在路径之后 |
| GetMapper + @PathVariable | 前端请求路径为：/category/detail{参数} | 参数拼在路径中 |
方式一：
（前端）
// 获取文章列表接口
export const articleListService = (params) => {
// 发送请求
// params 可能是一个对象，比如 { category: 'technology', limit: 10 }
return request.get('/category/detail',{params : params})
}
（后端）
@GetMapping("/detail")
public Result<Category> getCategoryDetail(@RequestParam(vlaue = 'id') Integer id) {
// 获取文章分类详情
return articleCategoryService.getCategoryDetail(id);
}方式二：
(前端)
export const getArticleByIdService = (id) => {
return request.get(`/article/${id}`);
}（后端）
@GetMapping("/article/{id}")
public ResponseEntity<Article> getArticleById(@PathVariable Long id) {
// 方法实现
}注意点：
1.针对一些非必填的参数，可以使用required关键字来标识，同时必须设置默认值defaultValue,如getOrder方法中对price参数的获取：
@RequestParam(
value = "name",
required = false,
defaultValue = "0") Integer name二、Post请求
前端发送特点：Post请求用于向服务器发送数据，数据可以以 application/json 或 application/x-www-form-urlencoded 格式发送。
后端接收特点：使用PostMapper + @RequestBody 或 @RequsetParam接收
具体的：
| 接收方式 | 适用情况 | 特点 |
| PostMapper + @RequestBody | 接收 JSON请求体格式 | |
| PostMapper + @RequsetParam | 接收处理表单数据 |
方式一：
（前端）使用
// 上传用户头像
export const userAvatarUploadService = (file) => {
let formData = new FormData();
formData.append('file', file); // 注意这里使用 'file' 作为键名，与后端 @RequestParam("file") 对应
// 发送请求
return request.post('/user/upload', formData, {
headers: {
'Content-Type': 'multipart/form-data' // 通常不需要显式设置这个头，因为 axios 或 fetch 会自动设置
}
});
}（后端）
@PostMapping()
public Result upload(@RequestParam MultipartFile file){
// 文件上传
return uploadService.upload(file);
}
}方式二：
（前端）
// 添加文章接口
export const articleAddService = (articleModel) => {
// 发送请求
return request.post('/article',articleModel)
}（后端）
@PostMapping()
public Result addArticle(@RequestBody @Validated Article article) {
// 添加文章
articleService.addArticle(article);
return Result.success();
}
三、PUT 请求
前端请求特点： PUT请求常用于更新数据资源，于POST请求写法类似，通过请求体发送数据
后端接收特点：使用 @PutMapper + @RequsetBody 接收 PUT 请求的 JSON 数据。
（前端）
// 修改文章接口
export const articleUpdateService = (articleModel) => {
// 发送请求
return request.put('/article',articleModel)
}
（后端）
@PutMapping()
public Result updateArticle(@RequestBody @Validated Article article) {
// 更新文章
articleService.updateArticle(article);
return Result.success();
}
四、DELETE 请求
前端发送特点：DELETE主要用于删除数据资源，通过URL发送资源的标识符，与GET请求书写
后端接收特点：通过@DeleteMapper + @PathVariable 接收标识符，@Requsetparam
方式一：
（前端）
// 删除文章接口
export const articleDeleteService = (id) => {
// 发送请求
return request.delete(`/article/${id}`)
}(后端)
@DeleteMapping(/{id})
public Result deleteArticle(@PathVariable @Validated Integer id) {
articleService.deleteArticle(id);
return Result.success();
}方式二：
（前端）
// 删除文章接口
export const articleDeleteService = (id) => {
// 发送请求
return request.delete(`/article?id=` + id)
}（后端）
@DeleteMapping()
public Result deleteArticle(@RequestParam @Validated Integer id) {
articleService.deleteArticle(id);
return Result.success();
}五、PATCH请求
前端请求特点：PATCH请求用于资源的部分内容的更新；可能会在资源不存在时去创建它
后端接收特点：使用 @PatchMapping + @Requestparam 或 @RequestBody
方式一：
（前端）
// 修改用户头像
export const userAvatarUpdateService = (avatarUrl) => {
let params = new URLSearchParams()
params.append('avatarUrl',avatarUrl)
// 发送请求
return request.patch('/user/updateAvatar',params)
}（后端）
@PatchMapping("/updateAvatar")
public Result updateAvatar(@RequestParam @URL String avatarUrl) {
// 更新用户头像
userService.updateAvatar(avatarUrl);
return Result.success();
}
方式二：
（前端）
// 修改用户密码
export const userPasswordUpdateService = (passwordData) => {
// 发送请求
return request.patch('/user/updatePwd',JSON.stringify(passwordData), {
headers: {
'Content-Type': 'application/json'
}})
}（后端）
@PatchMapping("/updatePwd")
public Result updatePwd(@RequestBody @Validated UserPwdDTO userPwdDTO) {
// 更新用户密码
return userService.updatePwd(userPwdDTO);
}六、三大注解的使用场景、区别、与总结
总结
| 注解 | 请求参数位置 | 请求方式 | 支持的Content-Type | 请求示例 |
|---|---|---|---|---|
| @PathVariable | Url | Get | Get请求没有Content-Type | /user/1 |
| @RequestParam | Url、Body | Get / Post / Put / Delete/ Patch | form-data，x-www-form-urlencoded | /user?name=wzc&age=23 |
| @RequestBody | Body | Post / Put / Delete / Patch | application/json |
@PathVariable
【支持的请求方式】
- 支持请求方式：GET
- 参数传递：在URL上直接传递
【使用场景】
在向服务端获取简单的数据的过程中可以使用，例如根据ID值查询学生信息，就会在前端发送GET请求，后台使用@GetMapper + @PathVariable接收
【优点】
简单类型的数据绑定，例如 int 、string
【缺点】
1. 当需要传递的参数过多，就不好写了，所以一般适用于单参数查询方法上
2. id暴露在url上，对于不方便泄露ID的值请求，最好不要使用，否则暴露网站url的特点。
3. 只支持Get方式，请求方式有局限性
4. 不支持复杂数据类型，自定义数据类型
【使用说明】
| 步骤 | 格式 | 说明 |
| 前端发送的请求URL | http://localhost:8080/user/detail/1 | - |
| 后端接收参数 | @GetMapper（“/user/detail/{id}”） | 这里的id是路径上的参数，传什么值接收什么值 |
| 后端映射值 | @PathVariable Integer id | 这里的方法参数id要与路径变量参数id同名，因为@PathVariable没有指定别名的注解变量 |
【注意事项】
-
@PathVariable注解源码中只有一个参数，不填的默认是绑定到与路径参数同名的形参变量
-
如果要接收多个路径变量，则需要声明多个@PathVariable变量
@RequestParam
【支持的请求方式】
- 支持请求方式：GET，POST,PUT,DELETE
- 参数传递：在Body中传递
- 支持的Content-Type：application/json, url
【使用场景】
对于多参数查询时比较常用到，比如跟据文章分类、文章标题内容模糊查询文章，就会发送POST请求，后台使用RequestParam接收
【优点】
能够轻松地从URL中提取参数。
【缺点】
1. 由于 url 长度有限制，所以参数需要限制数量和值的长度，不然url过于臃肿。
2. 安全性较低，因为查询参数会暴露在URL中。
3. 对于复杂或结构化的数据（如JSON、XML等）处理不够灵活。
【使用说明】
- 在控制器方法的参数前使用
@RequestParam注解，并指定参数名称（可选）和默认值（可选）。 - 例如：
@RequestParam(name = "id", defaultValue = "1") Long id。
【注意事项】
@RequestParam拥有三个参数：
1. value、name 属性：标识请求参数名（必须配置）
2. required属性 ：参数是否必传，默认为 true，可以设置为非必传 false；（如果设置了必传或默认，请求未传递参数，将会抛出异常）
3. defaultValue：参数默认值，如果设置了该值，required 将会自动设置为 false
@RequestBody
【支持的请求方式】
- 支持请求方式：GET，POST,PUT,DELETE、PATCH
- 参数传递：在Body中传递
- 支持的Content-Type：application/json, application/xml
【使用场景】
最常用的一种注解，用于处理HTTP请求的请求体（body）中的数据，用于POST、PUT和PATCH请求中，接收JSON、XML等结构化的数据
【优点】
1. 自动将请求体中的数据反序列化为Java对象。
2. 能够处理复杂和结构化的数据。
3. 提供了数据验证和绑定的功能。
【缺点】
对于简单数据（如单个字符串、整数等）处理不够简洁。
【使用说明】
- 在控制器方法的参数前使用
@RequestBody注解。 - 确保请求体的内容类型（Content-Type）与Java对象的类型相匹配（如application/json）。
- 例如：
@RequestBody MyObject myObject。
【注意事项】
1. 使用@RequestBody时，通常不需要在方法参数中指定参数名称，因为整个请求体都会被反序列化为指定的Java对象。
2. @RequestBody注解只拥有一个参数 : required 默认为 true，即对象中的属性必须有一个要传，否则会抛出异常。
七、四大请求方式总结
以下是根据您提供的信息整理成的表格，对HTTP请求方式、数据库操作、请求参数位置及Spring MVC注解进行了总结：
| HTTP请求方式 | 数据库操作 | 请求参数位置 | Spring MVC注解 | 说明 |
|---|---|---|---|---|
| GET | 查询 | URI查询参数 | @RequestParam（也可通过URI路径变量@PathVariable获取） | 不修改数据库，只是查询；参数通常放在URL中 |
| POST | 增加 | RequestBody | @RequestBody, @RequestParam（非标准，但可用于简单参数） | 增加记录到数据库；复杂数据通常放在请求体中 |
| PUT | 更新 | RequestBody | @RequestBody | 更新数据库中的记录；数据通常放在请求体中 |
| DELETE | 删除 | 通常无参数（可通过URI路径变量@PathVariable指定资源） | @PathVariable（用于指定要删除的资源ID） | 从数据库中删除记录；通常不需要额外参数，除非是指定资源的ID |
注意：
-
@PathVariable：用于处理URI路径中的变量部分，通常用于指定要操作的具体资源（如通过ID删除特定记录）。
-
@RequestHeader和@CookieValue：分别用于处理HTTP请求头和Cookie中的信息。
-
请求参数位置：对于GET请求，参数通常放在URL的查询字符串中。对于POST、PUT和DELETE请求，复杂数据通常放在请求体中（使用
@RequestBody），而简单数据（如ID）可能通过URI路径变量（@PathVariable）或表单数据（在POST请求中，使用@RequestParam，但内容类型为application/x-www-form-urlencoded）传递。 -
DELETE请求与参数：虽然DELETE请求通常不需要额外的请求体参数（因为它通常用于删除由URI指定的资源），但有时可能需要通过URI路径变量来指定要删除的资源ID。
- 处理 request uri 部分的注解，路径参数变量：@PathVariable；
- 处理request header部分的注解： @RequestHeader, @CookieValue，@RequestParam；
- 处理request body部分的注解：@RequestParam， @RequestBody；
原文地址：https://blog.csdn.net/wzc200406/article/details/142983161
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！