前端的请求方法,后端是怎么得到的?

上一章节 , 我们讲了前端HTTP 1.1 的请求方法 :

传送门: SpringMvc中的请求注解@RequestMapping

同时上一章也留下了一个未解决的问题 : 不同的请求方法和json对象的联系 !

我们用curl命令来尝试对baidu.com 进行一个POST请求:

首先附上HTTP请求的组成图


一些解析我已经标注在图中了 .

简单来说 , 并不是不同的请求方法会封装成不同的json字符串 . 而是json字符串中会封装不同的请求方法 .

而对于页面进行某一个操作 , 这个操作使用怎样的一个HTTP请求方法时前端来定义的 . 不仅如此 , 前端还会传一系列数据(比如HTTP协议版本号 , 请求的目的地HOST)等等一系列信息给后端 . 这些信息被打包成json类型的字符串 .

而后端Spring 会解析这些字符串 , 去判断是哪一个HTTP请求方法 , 从而去根据注解 , 找到处理请求的方法 .

这时最粗略的解释;

下面我给大家说一说比较粗劣的解释 ;

在此之前我们要先讲讲 Tomcat 和 Servlet

Tomcat

Tomcat实际上就是web服务器和Servlet容器的结合体 . (类似于钢铁加鲁鲁和战斗暴龙兽合体)

而web服务器的作用是将主机上的某一个资源映射成URL供外界访问 . 例如:你要在自己的电脑上去访问我写的文章 , 你是怎么实现访问的呢 ? 就是通过URL .

Servlet 容器是用来存放 Servlet 对象的 . (嗯哼 , 不是把你们不想要的男朋友塞进来 .) 我们为什么能够通过URL进行访问呢 ? 肯定是会有一些步骤的吧 ? -----------一般来说总体确实是有三个步骤:
1.接收请求
2.处理请求
3.响应请求

任何一个请求都必须经过这三步 ! (如果你们非要把不要的男朋友塞进来 ,请把这里想象成男德学院 , 按照你的想法 , 对于男朋友进行处理 , 再还给你 )

诶 ! 是把你塞进来的男朋友还给你 ! 不是还给别人 ! 那么我们会发现一个共性 : 那就是从哪儿发出请求 , 我们就要把处理后的请求返回到哪儿去 !

因此 , 聪明的程序员开始造轮子 , 接收请求和响应请求是共性功能 , 没有差异性 . 那我们就把接收和响应抽取成web服务器 !

剩下的处理请求 , 因为大家对男朋友的需求不一样嘛 , 有的要会做菜 , 有的要会洗衣 . 所以没关系 , 我们将它抽取成Servlet , 你自己去编写处理逻辑 .

好了 , 男女朋友的举例在此就戛然而止 , 因为后面再用就不太合适了 .

Servlet

回归正文 , 随着互联网的发展 , 出现了三层架构 ! 所以一些逻辑就从Servlet中抽取出来 , 到了 Dao 和 service 中 . 同时由于Servlet 并不擅长向浏览器输出HTML界面 , 因此 JSP 应运而生 .

直到后来 , Spring出来了 , SpringMVC 完全取代了Servlet . SpringMVC核心组件DispatcherServlet实际上就是一个Servlet . 只不过他自立门户 , 在里面又封装了一条逻辑 . (DispatcherServlet 其实我也还是一个蒙圈的状态 , 希望和大家一起学习 , 现在只要知道有这么个东西)

现在我们开始用比较粗略的语言和解释 , 来看看具体实现 .

首先我们有一个HTTP请求 , 传到了Tomcat .

Tomcat 通过字符串解析,把各个请求头Header , URL , QueryString都封装进一个Request对象中 .
(有点类似于我们的类中封装各种字段 , 然后写一个@Data注解 , 让它能自动生成set , get 方法 . )

然后我们将这个Request空对象传给Servlet进行逻辑处理 ! 进行逻辑处理之后通过 response.write() 方法 写入到Response的缓存区 .

Tomcat会在逻辑处理结束后 , 从缓存区拿到这个对象 , 遍历一遍 ! 组装成HTTP响应给客户端.