HTTP基础+分层解耦
注意:大部分截图来自黑马 ,仅个人学习使用
HTTP协议
- 请求协议
- 请求数据格式
- 请求行 (请求方式、资源路径、协议)
- get方式:路径中可以携带参数,请求大小在浏览器当中是有限制的
- post方式:请求参数在请求体当中,请求大小没有限制
- 请求头(key:value)
- Host:请求的主机名、
eg:localhost:8080 - User-Agent:浏览器版本
- Accept:表示浏览器能接受的资源类型,如
text/*,image/*或者*/*表示所有 - Accept-Language:表示浏览器偏好的语言,服务器可以据此返回不同语言的网页
- Accept-Encoding:表示浏览器可以支持的压缩类型,例如gzip,deflate,br等
- Content-Type:请求主题的数据类型
- Content-Length:请求主题的大小(单位:字节)
- Host:请求的主机名、
- 请求体:POST请求,存放请求参数
- 请求行 (请求方式、资源路径、协议)
- 请求数据的获取(调用HttpServletRequeest)–通常AI
- 获取请求方式
1
String method = request.getMethod();//GET
- 获取请求的url地址
1
2String url = request.getRequestURL().toString();//获取完整地址
String uri = request.getRequestURI();//获取资源路径地址- 获取请求的协议
1
String protocol = request.getProtocol();//HTTP/1.1
- 获取请求参数
1
String n=request.getPArameter();
- 获取请求头 -Accept(示例)
1
String accpet = request.getHeader("Accept");
- 请求数据格式
- 响应协议
- 响应数据格式
- 响应行(协议、状态码、描述)
1.常见响应状态码

- 响应头(格式key:value)
- 响应体(存放响应数据)
- 响应行(协议、状态码、描述)
- 响应数据设置
与请求类似,不赘述
- 响应数据格式
分层解耦
三层架构-单一职责原则
拆分后便于复用、后期维护
接收请求、响应数据-Controller
- 控制层,接受前端发送的请求,对请求处理并响应数据
逻辑处理-Service
- 业务逻辑层,处理具体业务逻辑
数据访问-Dao
- 持久层,负责数据访问操作
增删改查
IOC与DI
- 概念
- 控制反转:IOC,对象创建控制权由程序自身转移到外部(容器)
- 依赖注入:DI,容器为应用程序提供运行时,所依赖的资源,称之为DI
- Bean对象:IOC容器中创建、管理的对象称之为Bean
- 入门
- 将Dao及Service层的实现类,交给容器处理---
@Component(加在实现类上,而非接口) - 为Controller及Service注入运行时所依赖的对象—
通过@Autowired从IOC容器中找到该类型的Bean,然后完成依赖注入
- 将Dao及Service层的实现类,交给容器处理---
- IOC详解

- 声明控制器的bean只能用@Controller
- 启动类默认扫描当前包及其子包
- 声明bean的时候,可以通过value属性指定bean的名字,如果没有指定,默认为类名首字母小写
- Di详解
- 注入方式:

- 优点:代码简洁,方便快速开发
- 缺点:隐藏了类之间的依赖关系、可能会破坏类的封装性

- 优点:能清晰地看到类的依赖关系、提高了代码的安全性
- 缺点:代码繁琐、构造参数过多会导致构造函数臃肿
- PS:如果只有一个构造函数,@Autowired注解可以省略

- 优点:保持了类的封装性,依赖关系更清晰
- 缺点:需要额外编写setter方法,增加了代码量
- 如果存在多个相同类型的bean,有以下三种解决方案
- 区别@Resource And @Autowired
@Autowired是Spring框架提供的注解,而@Resource是JavaEE规范提供的
@Autowired默认是按照类型注入,而@Resource默认是按照名称注入
- 注入方式:
结语
目前还有好多不理解的地方,希望下次回来看这篇的时候能够明白再做整理,也可能不回来了
https://oyuovo.github.io.git/2025/10/21/HTTP%E5%9F%BA%E7%A1%80-%E5%88%86%E5%B1%82%E8%A7%A3%E8%80%A6/
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Blog of Sof!
评论









