mvc设计模式

MVC设计模式是Model-View-Controller的缩写，它是一种用于设计用户界面的软件设计模式。Spring MVC是Spring框架的一个模块，它提供了一种基于Java的方式来实现MVC设计模式。

以下是Spring MVC中MVC设计模式的组成部分和工作原理： 

Model（模型）

• 定义：模型代表应用程序的数据结构和业务逻辑。它直接与数据库或其他数据源进行交互，获取或存储数据。
• 在Spring MVC中：模型通常是Java类（如POJOs, JavaBeans），这些类可以与数据库表对应，通过ORM框架与数据库交互，或者是业务逻辑的实现。
• POJOs是模型Model！POJOs是模型Model！POJOs是模型Model！

View（视图）

• 定义：视图是用户界面的表示。它定义了数据如何显示给用户。
• 在Spring MVC中：视图可以是JSP、Thymeleaf、FreeMarker等模板引擎生成的页面。Spring MVC通过视图解析器来确定如何渲染数据。

Controller（控制器）

• 定义：控制器处理用户的输入，并决定如何响应。它在模型和视图之间充当中介，根据用户的输入或请求更新模型，并选择合适的视图进行响应。
• 在Spring MVC中：控制器通常是标注为@Controller或@RestController的Java类。这些类包含用于处理特定URL请求的方法，这些方法通常使用@RequestMapping或其变种（如@GetMapping、@PostMapping等）进行注解。

Spring MVC的工作流程

1. 用户发送一个HTTP请求。
2. 前端控制器（DispatcherServlet）接收此请求。
3. DispatcherServlet查询一个或多个处理器映射（HandlerMapping）来找到处理这个请求的控制器。
4. 控制器处理请求，并返回一个模型和视图（ModelAndView）给DispatcherServlet。
5. DispatcherServlet查询视图解析器来确定如何渲染视图。
6. 视图被渲染，并将响应返回给用户。

MVC设计模式允许开发者将业务逻辑、用户界面和用户输入分离开来，这样做有助于提高应用程序的模块化和可维护性。Spring MVC提供了一套完整的框架，使Java开发者能够轻松地实现MVC设计模式并创建Web应用程序。

---

4xx错误

4xx的HTTP状态码表示客户端错误，意味着由于客户端提供的信息有误或请求方式不当，导致服务器无法处理请求。以下是一些常见的4xx状态码及其描述：

1. 400 Bad Request（错误的请求）:

   • 描述：这是一个通用错误响应，表示服务器不能处理请求，因为客户端的请求语法不正确、请求参数无效或请求格式错误。
   • 可能的原因：例如，客户端发送的JSON数据格式不正确或请求中的参数值超出了有效范围。前者在测试中非常常见……

2. 401 Unauthorized（未授权）:

   • 描述：客户端在请求需要身份验证的资源时未提供有效的身份凭证，或提供的凭证是无效的。

3. 403 Forbidden（禁止）:

   • 描述：服务器已经理解了请求，但拒绝执行它。与401不同，身份验证不会有助于解决问题，通常是因为服务器不想让用户访问这个资源。

4. 404 Not Found（未找到）:

   • 描述：服务器找不到所请求的资源。这通常意味着用户请求的URL是错误的，或请求的资源在服务器上不存在。

5. 405 Method Not Allowed（方法不允许）:

   • 描述：所请求的资源已被找到，但所使用的HTTP方法不被允许。
   • 重点：例如，当用户试图使用POST请求访问一个只允许GET请求的资源时，服务器会返回此状态码。响应中应该包含Allow头，列出资源支持的HTTP方法。

6. 406 Not Acceptable（不可接受）:

   • 描述：服务器无法返回与请求头中的Accept字段相匹配的响应，表示客户端请求的内容格式服务器无法提供。

7. 409 Conflict（冲突）:

   • 描述：请求无法完成，因为服务器上的资源存在冲突。例如，在版本控制场景中，当用户尝试更改已经被其他人更改的资源时，可能会收到此错误。

8. 429 Too Many Requests（请求过多）:

   • 描述：用户在给定的时间段内发送了太多的请求，通常由于速率限制而触发。

---

JWT

JSON Web Token（JWT）是一个开放的标准（RFC 7519），它定义了一种简洁、自包含的方式来表示在双方之间传输的信息。由于信息是经过数字签名的，所以可以验证和信任该信息。

JWT常用于前后端分离的认证系统。在这种场景下，用户登录后，后端会生成并返回一个JWT给前端。前端每次发送请求时都会带上这个JWT，后端通过验证JWT来确定用户身份并响应请求。

JWT的结构大致如下：

1. Header（头部）: 描述令牌的元数据，如签名算法。
2. Payload（有效载荷）: 包含声明（claims）。声明是关于实体（通常是用户）以及其他数据的陈述。
3. Signature（签名）: 对头部和有效载荷的加密签名，确保令牌的完整性和验证其发起者。

这三部分通过.连接成一个字符串，形成JWT。

JWT的使用流程:

1. 用户使用凭证（如用户名和密码）登录。
2. 服务器验证凭证并生成JWT。
3. 服务器将JWT返回给客户端。
4. 客户端将JWT存储起来，常见的存储方式有：Cookie、LocalStorage或SessionStorage。
5. 客户端在后续的每个请求中都将JWT放在请求头（如Authorization头）中，并发送给服务器。
6. 服务器接收请求后，验证JWT。如果验证成功，则处理请求；如果验证失败，返回一个错误响应。
7. JWT可以设置过期时间，当令牌过期后，用户需要重新登录获取新的令牌。

JWT的优点:

• 无状态性: 服务器不需要保存JWT。每次请求都带上JWT，服务器只需验证JWT就可以确定用户身份。
• 自包含: JWT可以包含所需的所有信息，无需额外查询。
• 灵活性: 可以在多个服务之间传递，非常适合微服务架构。

JWT的缺点:

• 安全问题: 一旦JWT被盗或泄露，攻击者可以使用它访问系统，直到JWT过期。因此，JWT的有效期应尽量短。
• 不易撤销: JWT是无状态的，一旦发出，直到其过期，都是有效的，这意味着黑名单机制或某种中心化检查会破坏其无状态性。
• 大小: 与简单的tokens相比，JWT可能较大，这可能增加请求的大小。

在实践中，JWT常与其他安全实践结合使用，如HTTPS、短的过期时间、刷新令牌等，以增加安全性。