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 文件，清楚表達網頁的結構與意義。