1.1 浏览器、服务器与网页资源

打开网页与按下按钮都可以改变画面，但背后的工作未必相同。打开网页时，浏览器可能向服务器请求文档；按钮也可能完全在浏览器内改变已有的文档。另一个按钮则可能先向服务器获取更多数据，再更新文档的一部分。理解这些差别，就能在选择框架之前解释网页应用程序的运行方式。

本节会追踪一个小型阅读列表网页的初次加载与本地交互，辨认请求指向的资源、负责每项变化的程序，以及所产生状态的生命周期。

1. 网页应用程序由多个部分协作

客户端与服务器描述的是角色，并非两种指定的实体计算机。一台笔记本电脑可以同时运行浏览器与本地网页服务器进程。浏览器仍然负责请求资源，服务器进程仍然负责处理这些请求。

服务器也不一定只发送磁盘上已有的文件。它可以运行程序来构造响应。例如，阅读列表服务可以选取可供阅读的书籍并生成 HTML，也可以返回 JSON 表示，供浏览器的 JavaScript 更新列表。两种情况都有请求、响应，以及资源的一种表示。

Web 描述这套通信与文档环境。Internet 是底层的网络基础设施，HTTP 则是使用这套设施的一种应用层协议。网页应用程序也可以在私有网络中运行，或通过同一台计算机上的本地服务器运行。

2. 把 URL 理解为有结构的地址

考虑以下示例地址：

https://reading.example.test/shelf/books?topic=web#practice

一般 HTTP 请求不会把片段发送至服务器。浏览器获取文档后可以使用片段，例如滚动至 id 为 practice 的元素。路径可以由应用程序路由处理，因此单凭路径不能判定服务器磁盘上存在同名文件。

协议方案也决定默认端口：HTTPS 通常使用 443，HTTP 通常使用 80。明确指定端口的地址，例如 http://localhost:8080/，则选用另一个端口。localhost 指正在运行浏览器的计算机，适合用来访问在该计算机上开发时运行的服务器。

3. 追踪一次文档请求

输入 HTTPS 地址会启动数项工作。浏览器识别主机，按需要获取其网络地址，并建立连接；HTTP 随后提供请求与响应的通信方式。部分工作可以沿用先前访问或缓存的结果，因此以下是概念上的流程，并非每次访问都必须逐项重新执行。

Browser                                      Server
   |                                            |
   |--- request the /shelf/index.html resource ->|
   |                                            | choose or generate content
   |<-- status, headers and HTML body -----------|
   |                                            |
   | parse HTML                                 |
   |--- request a referenced stylesheet -------->|
   |<-- stylesheet response ---------------------|
   | build the displayed page                   |

请求包含方法、目标与标头；部分方法也会带有主体。响应包含状态、标头，而且通常带有主体。以下以简化的 HTTP/1.1 形式示范：

GET /shelf/index.html HTTP/1.1
Host: reading.example.test
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>
<html lang="en">
  <head><title>Reading shelf</title></head>
  <body><h1>Reading shelf</h1></body>
</html>

HTML 文档可以引用 CSS、JavaScript、字体与图片。读者看见的网页由这些资源组合而成，未必只来自一个响应。多个请求的执行时间可以重叠，也可以复用缓存资源。反过来说，一张图片的请求失败，并不表示 HTML 文档的请求也失败。

这些状态代表不同的结果。更改 CSS 颜色不能修正错误的资源路径；修正路径也不能修复在生成响应时失败的服务器程序。

4. 分清结构、呈现与行为

HTML、CSS 与 JavaScript 相互协作，但分别回答不同的问题。

HTML 是标记语言，元素描述文档的结构。CSS 提供呈现规则。JavaScript 执行指令，并可以改变浏览器对文档的表示，也就是文档对象模型（Document Object Model，DOM）。框架同样在这个环境内运行；理解各部分的基本角色，有助于解释框架生成了什么。

浏览器运行客户端 JavaScript。服务器也可以运行 JavaScript，例如使用 Node.js，但两者属于不同的运行环境。服务器脚本只改变自身某个变量，不能直接改变已显示在浏览器中的网页。它必须通过响应或其他支持的通信机制，发送浏览器可以使用的结果。

5. 一个完整的本地交互

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Reading counter</title>
    <style>
      body { max-width: 38rem; margin: 2rem auto; padding: 0 1rem; }
      button { font: inherit; padding: 0.5rem 1rem; }
    </style>
  </head>
  <body>
    <main>
      <h1>Reading counter</h1>
      <p>Pages recorded: <output id="count" aria-live="polite">0</output></p>
      <button id="record" type="button">Record one page</button>
    </main>
    <script>
      let count = 0;
      const display = document.querySelector("#count");
      const button = document.querySelector("#record");

      button.addEventListener("click", () => {
        count = count + 1;
        display.textContent = String(count);
      });
    </script>
  </body>
</html>

6. 观察负责的层次来诊断问题

浏览器开发者工具可以检验解释，无须只凭外观推断所有事情。

1. 在文档检查器中找出输出元素。按下按钮，观察其文本节点改变。
2. 网页由本地服务器提供时，在 Network 面板检查初始文档请求，并比较其响应与所引用资源的请求。
3. 清空网络记录，再按计数按钮。所提供的处理函数不会引起请求。
4. 重新加载，把原始响应或文件内容与当前的 DOM 比较。原始代码加载后，脚本仍可以改变 DOM。

网页看起来有问题时，先提出精确的问题：资源是否已获取？文档结构是否正确？样式规则是否生效？处理函数是否更新了预期的状态与元素？不同问题会指向不同的证据。

练习

1. 辨认工作的执行位置

对以下每项操作，指出主要负责的层次：HTML、CSS、浏览器 JavaScript 或服务器程序，并解释理由。

1. 把书名标记为标题。
2. 画面变窄时，把两栏改成一栏。
3. 点击后增加本地阅读计数。
4. 服务只返回符合查询参数的书籍。

2. 在明确假设下计算资源数目

一份文档引用一份样式表、一份脚本与两张不同的图片。假设缓存为空、没有重定向、这些文件不再引用其他资源，而且每个资源的请求都成功。连同文档本身，共需要多少次资源请求？这是否表示所有请求必须逐一执行？

3. 解释重新加载的结果

学习者按计数按钮五次，关闭标签页，再打开同一网页。他预期看见 5，却看见 0。这是否必然表示点击处理函数有错？指出程序中可以解释这个结果的证据。

4. 解析目录改变后的地址

一份 HTML 文件由 /shelf/index.html 移至 /courses/web/index.html。文档没有 base 元素。比较移动前后，theme.css 与 /assets/book.svg 各会解析为什么地址。

接着阅读语义化 HTML 文档，清楚表达网页的结构与意义。