作为 Web 工程师,其实这是一个很好的面试题,方便了解候选人对于 Web 生命周期中的理解程度。很多人写过相应的文章,这里只是整理梳理下,方便自己熟悉。
简单的说:
- 浏览器发送请求给服务器
- 服务器接受请求,发送 HTML 给浏览器
- 浏览器解析 HTML,显示网页
这当然是最简单的过程,我们可以一步一步深入。
我们先来看看第一部分:
当我们从浏览器发送请求给服务器的时候,我们发送的是什么?
其实很简单,只需要描述清楚一个经典的哲学问题:
- 去哪里?
- 做什么?
举个例子:如果 URL 是: juejin.im/editor/draf…
如何描述去哪里?
浏览器会通过 DNS 服务器,解析到域名:juejin.im 所对应的 IP 地址。然后请求到相应的服务器。(如何解析域名到相应的 IP 地址?)也就是说,域名描述了去哪里。
如何描述需要做什么?
这就是 URL 需要描述清楚的事情。URL 只是一个约定,约定以何种方式,做何种事情,目前比较流行的规范是 RESTFul 规范。
比如当前 URL 描述的是:在 Editor 下取得 ID 为 5c9b8cb86fb9a071071944e2 的 draft。
对于 URL 的发送请求的方式有分类,经典的类型是 GET 和 POST。但是 RESTFul 中一般使用四种:GET,PUT,POST,DELETE。 个人基本将他们分为两派,
- 索取派:GET,告诉服务器我要什么。
- 命令派:PUT,POST,DELETE,告诉服务器,我可以什么都不要(也可以要),但是你要帮我做些事情。
当然,要求人家服务器做事,也不能什么都不给别人。我们还需要解决的一个问题是:
在我要求你做事前,我能给你点什么?
就像诸位小时候去外婆家,外婆总会给你塞点什么,浏览器发送请求时的带货能力,也是很强的。
- URL 本身夹带参数,如本例中的 5c9b8cb86fb9a071071944e2 就是参数 ID。
- Querry string。以 ?开始,通过 & 分隔。
- Cookie,每次请求都会被随带到服务器里,服务器也会把相应的 Cookie 返回到浏览器。
- Form Data,只出现在『命令派』中。
- Request Header,一般用于描述请求本身,也可以自定义,比如常用的有 token,API Version 之类。
没写完,以后有空再更新。