Java-常见面试题收集(六)

十三 RESTful

1 前后端分离的优点

  前后端分离是种架构模式，前端指的是生成 HTML 的那个服务，它可以是一个仅仅生成 HTML 的 Web 服务器，也可以是在浏览器中通过 JS 动态生成HTML 的 单页应用。实践中，有实力的团队往往在实现前后端分离里时，前端选用 node 服务器，后端选用 C#、Java 等。一般来说，后端负责提供数据接口，不再渲染模板，以 json 格式返回数据。前端与后端进行交互，得到需要数据并加以展示。
  优点：

1.责任分离，谁擅长开发啥，让谁负责啥
2.前后端解耦，接口复用（前端和客户端公用接口），减少开发量
3.各司其职，前后端同步开发，提升工作效率。定义好接口规范。
4.更有利于调度（mock）、测试和运维部署

2 REST 与 RESTful

  REST（英文：Representational State Transfer，简称 REST）描述了一个架构样式的网络系统，比如 web 应用程序。在目前主流的三种 Web 服务交互方案中，REST 相比于 SOAP（Simple Object Access protocol，简单对象访问协议）以及 XML-RPC 更加简单明了，无论是对 URL 的处理还是对 Payload 的编码，REST 都倾向于用更加简单轻量的方法设计和实现。值得注意的是 REST 并没有一个明确的标准，而更像是一种设计的风格
  REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
  RESTFUL 是一种网络应用程序的设计风格和开发方式，基于 HTTP，可以使用XML 格式定义或 JSON 格式定义。RESTFUL 适用于移动互联网厂商作为业务接口的场景，实现第三方 OTT 调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源

3 RESTful 有哪些特点

1.每一个 URI 代表 1 种资源；
2.客户端使用 GET、POST、PUT、DELETE 4 个表示操作方式的动词对服务端资源进行操作：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT 用来更新资源，DELETE 用来删除资源；
3.通过操作资源的表现形式来操作资源；
4.资源的表现形式是 XML 或者 HTML；

4 RESTful API 的优点和缺点

  优点：简单易用，它把任何对象当成一个资源，非常适合微服务提供的请求返回。
  1.前后端分离，减少流量；
  2.安全问题集中在接口上，由于接受 json 格式，防止了注入型等安全问题；
  3.前端无关化，后端只负责数据处理，前端表现方式可以是任何前端语言（android，ios,html5）；
  4.前端和后端人员更加专注于各自开发，只需接口文档便可完成前后端交互，无需过多相互了解；
  5.服务器性能优化：由于前端是静态页面，通过 nginx 便可获取，服务器主要压力放在了接口上。

  缺点：
  1.多端 (多次数据交互)；在 RESTful 服务中一个 URL 表示一个资源。因此，当要获取多个资源时你必须请求多个不同的 URL，进而带来多次数据交互。
  2.过度获取/获取后 数据；前端需要某个对象部分字段，一个 API 请求后返回一个完整对象，造成资源浪费
  3.API 版本控制；当项目因为升级导致 API 版本变动，新变动的 URL，让 API 的维护和使用变得困难，并且经常导致重复的代码。替代方案：GraphQL API

5 设计 RESTful API

  1.请求路径–以当前操作的资源作为 url 地址，一般使用复数
  2.请求方法–以 web 请求方法作为资源操作动作， 约定： 增：POST 删：DELETE 改：PUT 查：GET
  3.请求参数–根据 api 接口实现逻辑决定，一般是业务决定
  4.求响应–根据需求决定，一般返回都是 json 格式

HTTP 方法	URL	动作
GET	http://[hostname]/api/users	检索用户列表
GET	http://[hostname]/api/users/[user_id]	检索单个用户
POST	http://[hostname]/api/users	创建新用户
PUT	http://[hostname]/api/users/[user_id]	更新用户信息
DELETE	http://[hostname]/api/users/[user_id]	删除用户

6 什么是安全的 REST 操作

  REST API 使用 HTTP 方法执行操作。一些不修改服务器资源的 HTTP 操作称为安全操作，包括 GET 和 HEAD。另一方面，PUT，POST 和 DELETE 是不安全的，因为它们修改了服务器上的资源。

7 幂等性为什么重要

  有一些 HTTP 方法，比如 GET。无论你使用多少次都产生相同的响应，向同一个 URI 发送多个 GET 请求将导致相同的响应而没有任何副作用。因此，这被称为幂等。
  另一方面，POST 不是幂等的，因为如果你发送多个 POST 请求，它将导致在服务器上创建多个资源，但是，如果你使用它来更新资源，PUT 也是幂等的。甚至可以使用多个 PUT 请求来更新服务器上的资源，并给出相同的最终结果。

8 常见 HTTP 请求方法

  1.OPTIONS 返回服务器针对特定资源所支持的 HTTP 请求方法，也可以利用向 web 服务器发送‘*’的请求来测试服务器的功能性
  2.HEAD 向服务器索与GET 请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传
输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
  3.GET 向特定的资源发出请求。注意：GET 方法不应当被用于产生“副作用”的操作中，例如在 Web Application 中，其中一个原因是 GET 可能会被网络蜘蛛等随意访问。Loadrunner 中对应 get 请求函数：web_link 和 web_url
  4.POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。Loadrunner 中对应 POST 请求函数：web_submit_data,web_submit_form
  5.PUT 向 指 定 资 源 位 置 上 传 其 最 新 内 容
  6. DELETE 请 求 服 务 器 删 除Request-URL 所标识的资源
  7.TRACE 回显服务器收到的请求，主要用于测试或诊断
  8.CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。

9 常见请求头有哪些？

  HTTP 最常见的请求头如下：
  Accept：浏览器可接受的 MIME 类型；
  Accept-Charset：浏览器可接受的字符集；
  Accept-Encoding：浏览器能够进行解码的数据编码方式，比如 gzip。Servlet能够向支持 gzip 的浏览器返回经 gzip 编码的 HTML 页面。许多情形下这可以减少 5 到 10 倍的下载时间；
  Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到；
  Authorization：授权信息，通常出现在对服务器发送的 WWW-Authenticate 头的应答中；
  Connection：表示是否需要持久连接。如果 Servlet 看到这里的值为“Keep-Alive”，或者看到请求使用的是 HTTP 1.1（HTTP 1.1 默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如 Applet，图片），显著地减少下 载 所 需 要 的 时 间 。 要 实 现 这 一 点 ， Servlet 需 要 在 应 答 中 发 送 一 个Content-Length 头 ， 最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小；
  Content-Length：表示请求消息正文的长度；
  Cookie：这是最重要的请求头信息之一；
  From：请求发送者的 email 地址，由一些特殊的 Web 客户程序使用，浏览器不会用到它；
  Host：初始 URL 中的主机和端口；
  If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回 304“Not Modified”应答；
  Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝；
  Referer：包含一个 URL，用户从该 URL 代表的页面出发访问当前请求的页面。
  User-Agent：浏览器类型，如果 Servlet 返回的内容与浏览器类型有关则该值非常有用；
  UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的 IE 浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和 CPU 类型

10 @RequestMapping 的作用

  @RequestMapping 是 Spring MVC 框架中的一个核心注解，用于处理 HTTP 请求并映射到相应的控制器方法。这个注解在 Spring Web 应用中起着至关重要的作用，它允许开发者将特定的 URL 路径与控制器方法关联起来，以便在接收到匹配该路径的 HTTP 请求时执行相应的方法。
  @RequestMapping 可以用于类级别或方法级别。当用于类级别时，它定义了该类中所有方法的共同映射信息，如基础 URL 或请求方式（GET、POST 等）。当用于方法级别时，它则针对该方法定义了更具体的映射信息。以下是 @RequestMapping 的一些主要用途和特性：

  1.定义 URL 映射：使用 @RequestMapping 可以很容易地将 URL 路径映射到控制器方法。例如，@RequestMapping(“/hello”) 会将 /hello 路径的请求映射到该方法。
  2.处理 HTTP 请求方法：@RequestMapping 可以指定处理的 HTTP 请求方法（如 GET、POST、PUT、DELETE 等）。这有助于根据不同的请求方法执行不同的操作。
  3.定义请求参数和路径变量：通过 @RequestMapping 的 params 和 value 属性，可以定义请求中必须包含的参数和路径中的变量。
  4.组合使用：@RequestMapping 可以与其他注解（如 @GetMapping、@PostMapping 等）结合使用，以简化常见的请求方法映射。
  5.跨控制器继承：当 @RequestMapping 应用于类级别时，该类中的所有方法都会继承该映射。这有助于在控制器之间共享基础的 URL 路径。
  6.灵活的映射规则：支持正则表达式和通配符，以便定义更复杂的 URL 映射规则。
  通过使用 @RequestMapping，开发者可以轻松地构建结构清晰、易于维护的 Web 应用，并根据不同的请求路径和方法执行相应的业务逻辑。

11 @Controller 和@RestController 的区别

  1.返回值处理：
  @Controller：这个注解用于传统的 MVC 模式。当使用 @Controller 注解的控制器方法返回视图名称时，Spring MVC 会通过视图解析器将其解析为实际的视图页面（如 HTML 页面）。因此，@Controller 注解的控制器方法通常返回的是渲染后的视图。
  @RestController：这个注解用于创建 RESTful 风格的控制器。它相当于 @Controller 和 @ResponseBody 的结合。@RestController 注解的控制器方法返回的数据不会经过视图解析器，而是直接作为响应内容发送到客户端。通常，这些数据以 JSON 或 XML 格式返回。因此，它更适用于与前端或其他系统之间的数据交互，以及作为移动应用程序的后端服务。

  2.使用场景：
  @Controller：适用于需要返回视图页面的场景，如传统的 Web 应用。
  @RestController：适用于构建 RESTful API，以及前后端分离的架构，其中前端仅负责展示数据，后端负责提供数据。

  总的来说，@Controller 和 @RestController 的主要区别在于它们对控制器方法返回值的处理方式和使用场景。选择使用哪个注解取决于你的应用需求，是需要返回视图页面还是直接返回数据。

12 什么时候需要在 Spring MVC 中使用@ResponseBody注释

  在 Spring MVC 中，@ResponseBody 注解通常用于指示一个控制器方法返回的值应该被写入到 HTTP 响应体中，而不是被解析为一个视图名称。这意味着，当你希望方法返回的数据（如 JSON、XML 等）直接作为 HTTP 响应发送回客户端时，你应该使用 @ResponseBody 注解。

  需要注意的是，如果你已经使用了 @RestController 注解来标记你的控制器类，那么你不需要再在方法上单独使用 @ResponseBody。因为 @RestController 本身就是 @Controller 和 @ResponseBody 的组合，它会自动将每个方法的返回值作为响应体返回。

13 @PathVariable的作用

 &emsp@PathVariable 是 Spring MVC 中的一个注解，用于将请求 URI 中的模板变量绑定到控制器方法的参数上。具体来说，当请求的 URI 符合某个带有占位符的模式时，Spring MVC 会自动将这些占位符的值提取出来，并注入到带有@PathVariable 注解的方法参数中。以下是 @PathVariable 的主要作用：

  1.提取 URI 变量：在 RESTful Web 服务中，我们经常使用 URI 路径来传递资源标识符。例如，/users/{userId} 中的 {userId} 就是一个 URI 变量。通过 @PathVariable，我们可以轻松地从 URI 中提取这个变量的值。

  2.简化方法参数绑定：有了 @PathVariable，我们不需要在控制器方法中手动解析 URI 或查询参数来获取所需的值。Spring MVC 会自动为我们完成这些工作，并将值注入到相应的方法参数中。

  3.增加代码的可读性和可维护性：使用 @PathVariable 可以使代码更加清晰和易于理解。它明确了方法参数与 URI 之间的关系，减少了手动解析 URI 的代码量，从而提高了代码的可读性和可维护性。

  4.支持类型转换：@PathVariable 支持将 URI 变量的值自动转换为指定的 Java 类型。这意味着如果 URI 变量是一个数字或日期等，Spring MVC 会尝试将其转换为相应的 Java 类型，并注入到方法参数中。

@RestController  
@RequestMapping("/users")  
public class UserController {  
  
    @GetMapping("/{userId}")  
    public User getUser(@PathVariable Long userId) {  
        // 在这里，userId 将从 URI 的路径部分（如 /users/123）中提取出来  
        // 然后，你可以使用这个 userId 来从数据库或其他数据源获取相应的 User 对象  
        User user = userService.findUserById(userId);  
        return user;  
    }  
}

  当请求 /users/123 时，Spring MVC 会自动将 123 这个值提取出来，并注入到 getUser 方法的 userId 参数中。然后，你就可以在方法内部使用这个 userId 来获取对应的用户信息。