当输入 URL 的时候，这个世界为我们做了什么

作为 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 之类。

没写完，以后有空再更新。