likes
comments
collection
share

【🎈4000字整理，通俗易懂】解释一下@ResponseBody注解

作者站长头像
站长
· 阅读数 9

解释@ResponseBody注解

@ResponseBody就像是一个指令，告诉Spring MVC：“嘿，我要你直接把我这个方法返回的东西放到HTTP响应里面，别去找什么视图来渲染了。”——如果这个地方你不懂什么是视图问题也不大，我后面会解释。继续看就完事了。

比如说，你有一个卖水果的网店，顾客在网页上点击了“购买苹果”的按钮。服务器上的某个方法就会负责处理这个请求，然后告诉顾客：“你的苹果已经准备好了！”

如果没有@ResponseBody，服务器可能会说：“哦，你买了苹果啊，那我给你找个页面告诉你苹果已经准备好了。” 但有了@ResponseBody，服务器就会直接说：“你的苹果已经准备好了！”然后就把这句话放到HTTP响应里，直接发送给顾客的浏览器。

这样，顾客就能看到一条简单的消息，而不是被导向一个新的页面。

再用程序举一个例子，假设你有一个返回水果名称的方法：

@GetMapping("/getFruit")
public String getFruit() {
    return "Apple";
}

如果没有@ResponseBody，Spring MVC可能会尝试找一个名为“Apple”的视图来显示。（注意，看不懂视图问题不大，后面会解释，继续看）但如果你加上@ResponseBody：

@GetMapping("/getFruit")
@ResponseBody
public String getFruit() {
    return "Apple";
}

那么，当你访问/getFruit这个URL时，你会直接在浏览器中看到“Apple”这个词，而不是被导向另一个页面。

扩展一波：@RestController注解就像是一个更高级的指令，它告诉Spring MVC：“我这个控制器里的所有方法，你都要把返回的东西直接放到HTTP响应里面。”这样，你就不需要为每个方法都加上@ResponseBody了。

解释什么是视图

小贴士： 注意，后面为什么突然扯到Spring MVC 呢？ 我们我们先来说一下SpringBoot和SSM的关系：

SpringBoot和SSM（Spring + Spring MVC + MyBatis）在Java开发中都扮演着重要的角色，但它们之间的关系并不是简单的包含或被包含。下面举个🌰例子🌰帮助理解：

想象一下，SSM就像一辆手动挡的汽车（话说比亚迪最近降价很猛，大家怎么看）。Spring是汽车的发动机，提供了动力和各种基础功能；Spring MVC则是汽车的变速器和传动系统，负责将发动机的动力传递到车轮上，同时管理着驾驶者与汽车之间的交互；MyBatis则是汽车的轮胎和悬挂系统，与地面直接接触，负责将汽车的动力转化为实际的行驶。

而SpringBoot则像是这辆汽车的自动挡版本。它并没有替换SSM中的任何一个组件，而是对它们进行了封装和优化，使得开发者能够更快速、更便捷地搭建和开发Java Web应用。

在SpringBoot中，很多SSM中需要手动配置和管理的细节都被自动处理了，就像自动挡汽车一样，驾驶者只需要踩油门和刹车，变速和传动的工作都由汽车自动完成。

所以，SpringBoot并不是SSM的替代品，而是它的一个增强版或者说是升级版。它继承了SSM的强大功能，同时简化了开发过程，使得开发者能够更加专注于业务逻辑的实现，而不是花费大量时间在配置和管理上。

也就是说，下面说到的Spring MVC的相关内容，大家要知道它（Spring MVC）是融合进了SpringBoot中并进行升级了的，不要觉得他们没啥关系就可以了

在Web开发中，当用户通过浏览器发起一个请求（比如点击一个链接或提交一个表单）到服务器时，服务器会处理这个请求并返回一个响应。

在Spring MVC这样的Web框架中，响应通常包括两部分：

  1. 状态码：比如200表示成功，404表示未找到等。
  2. 响应体：这是实际返回给浏览器的数据，通常是HTML、JSON、XML等格式的内容。

视图在这里通常指的是用于渲染响应体的模板。

在Spring MVC中，视图可以是多种类型，比如JSP（JavaServer Pages）、Thymeleaf、FreeMarker等模板引擎的模板文件，或者是直接返回JSON或XML数据的逻辑。

当你返回一个字符串（比如"Apple"）作为控制器方法的返回值时，Spring MVC会默认认为这个字符串是一个视图的名称，并尝试找到一个对应的视图来渲染。它会查找是否有一个名为“Apple”的视图模板，然后使用这个模板来生成响应体的内容。

下面会提到 RESTful API 这边先简要解释一下

非RESTful API和RESTful API之间的主要区别体现在设计思路、URL结构、HTTP方法使用以及数据交互方式上。

下面烤个🌰：

非RESTful API和RESTful API之间的主要区别体现在设计思路、URL结构、HTTP方法使用以及数据交互方式上。以下是它们之间具体的差异：

设计思路：

  • 非RESTful API：通常更侧重于实现特定的功能，其URL结构往往直接反映了这些功能。例如，你可能会看到像/api/getList/1或/api/getList?page=1这样的URL，它们直接在路径或查询参数中描述了所执行的操作。
  • RESTful API：强调资源及其状态转移的概念。在RESTful API中，URL被用来描述资源，而不是操作。例如，一个表示用户资源的URL可能是/users/1，其中1是用户的唯一标识符。RESTful API使用HTTP方法来描述对这些资源执行的操作，如GET、POST、PUT和DELETE，分别对应查询、创建、更新和删除操作。

HTTP方法使用：

  • 非RESTful API：通常主要使用GET方法获取数据，而其他操作（如创建、更新或删除）可能都通过POST方法实现，这可能导致URL和请求体结构变得复杂和难以管理。
  • RESTful API：每种HTTP方法都有明确的语义：GET用于获取资源，POST用于创建新资源，PUT或PATCH用于更新资源，DELETE用于删除资源。这种设计使得API更加直观和易于理解。

数据交互方式：

  • 非RESTful API：在返回数据时，可能使用各种格式，如XML、JSON等。对于成功的操作或错误情况，通常依赖返回数据中的特定字段来表示状态。
  • RESTful API：通常使用JSON作为数据交换格式。此外，RESTful API通过HTTP状态码来表示不同的结果，如200表示成功，400表示客户端错误，500表示服务器错误等。这种设计使得API的响应更加标准化和易于处理。

扩展性和可维护性：

  • RESTful API由于其清晰的结构和语义，通常更容易扩展和维护。它使得开发者能够更容易地理解API的工作方式，从而更容易地添加新功能或修改现有功能。
  • 非RESTful API可能会因为缺乏统一的结构和语义而导致在扩展和维护时遇到更多的困难。

工作中，很多时候我们的方法需要直接返回数据而不是视图的名称。

尤其是当我们开发RESTful API时，我们更希望直接返回JSON或XML格式的数据。

这时候，@ResponseBody注解就非常有用，因为它告诉Spring MVC不要把这个字符串当作视图名称来处理，而是直接把它作为响应体的内容返回给客户端。

例如，如果你有一个返回用户信息的方法：

@GetMapping("/user")
public User getUser() {
    User user = new User();
    user.setName("你的人类朋友");
    user.setAge(18);
    return user;
}

如果没有@ResponseBody，Spring MVC会尝试找一个名为“User”的视图来渲染，这显然不是我们所期望的。加上@ResponseBody之后：

@GetMapping("/user")
@ResponseBody
public User getUser() {
    User user = new User();
    user.setName("你的人类朋友");
    user.setAge(18);
    return user;
}

Spring MVC就会直接将User对象转换为JSON或XML格式（取决于你的配置和客户端的请求头），并作为响应体的内容返回给客户端。

在大多数RESTful API的场景下，你不会返回一个视图的名称作为控制器方法的返回值，而是使用@ResponseBody来直接返回数据。所以你以后在工作的时候，直接在控制器类写上@RestController就可以了，不再用@Controller

最后

下次见咯

溜🚗~

转载自:https://juejin.cn/post/7344260010853384227
评论
请登录