Client / Server / API：同一個功能其實跨了多個 Runtime

Learning outcomes

• 能區分 client runtime 與 server runtime。
• 能把 API 視為 input/output contract。
• 能說明 UI validation 與 server validation 的責任差異。
• 能 trace 一次 Browser fetch 從 event 到 response render。

1. Client

Browser
  HTML / CSS / JS
  local UI state
  user events
  network requests

Client code 在使用者環境執行，使用者可以觀察甚至修改，因此不能當可信 security boundary。

2. Server

Server process
  routes
  validation
  authentication
  authorization
  business logic
  database access

Server 是可信邊界的一部分，但它本身也要正確實作 policy/validation。

3. API 是 Contract

GET /api/courses

Response 200:
[
  {
    "id": 1,
    "title": "JavaScript"
  }
]

Contract 包含 method/path、input、status、response shape、auth requirement，不只是一個 URL。

4. Browser fetch

const response =
  await fetch(
    "/api/courses"
  );

if (!response.ok) {
  throw new Error(
    "HTTP "
    + response.status
  );
}

const courses =
  await response.json();

fetch resolve 不代表 HTTP 2xx；要檢查 response status。

5. Trust Boundary

Browser says:
score = 999
owner_id = "admin"

Server must:
validate score
derive trusted identity
authorize operation

Client validation 是 UX；Server validation/authorization 才能保護資源。

Project checkpoint：Request Journey Map v10

User clicks "Load courses"
  ↓
Client event handler
  ↓
GET /api/courses
  ↓ DNS/TLS/HTTP
Server route
  ↓
business/data layer
  ↓
JSON response
  ↓
Client state
  ↓
DOM render

至此 01–10 已經把「輸入網址到互動畫面」串成一條完整骨架；後面再深入 DB/Auth/Git/Cloud。

Debug evidence：UI 顯示錯誤要往哪查

1. event 有沒有觸發？
2. request 有沒有送出？
3. status/body 是什麼？
4. server log 是否收到 request？
5. response 進 state 了嗎？
6. render 是否使用正確 state？