第3章 浪潮之巅的Web
沿资源定位、连接建立、请求发送、服务处理和表示返回追踪 Web 请求，用超时、认证、重试和重复副作用实验解释远程边界。
学习目标
- 能沿定位资源、建立连接、发送请求、服务处理和返回表示追踪一次 Web 请求，并指出每层的输入与输出
- 能用 URI、HTTP 消息、超时、认证和 request ID 解释客户端与服务端如何在远程故障中保持可观察边界
- 能在正常、边界和故障场景中区分连接失败、协议失败、服务失败和重复副作用，并从干净状态重放
为什么需要这一机制
Web 的关键变化不是把页面搬到浏览器，而是把一次交互拆成多个可以独立演进、独立失败的进程边界。URI 标识资源，HTTP 交换消息，客户端呈现表示，服务端维护状态；请求从客户端穿过网络到服务和数据层，任何一段都可能超时、拒绝或重复。
核心合同
↡本页把 Web 重构为由 URI、HTTP 消息、客户端、服务端和数据状态连接的远程协议系统，一次请求跨越多个故障边界。路径中的每个箭头都需要合同：资源如何定位、连接如何建立、消息如何编码、服务如何处理、状态何时提交、表示如何返回。响应可丢失而服务端已完成时，request ID 和幂等键是恢复判断的证据。
五个节点到机制证据
定位资源
↡客户端用 URI 和方法语义确定要访问的资源、动作和目标服务，并生成可追踪的请求身份。记录 URI、方法、参数、认证上下文和 request ID。URI 解析成功不代表目标服务可达，也不代表动作可以安全重试。
建立连接
↡客户端通过网络、传输和安全握手建立到目标服务的通信路径，过程中可能发生超时、拒绝或中断。记录 DNS/地址、连接耗时、TLS 或认证握手和超时原因。连接未建立时不能把错误伪装成业务拒绝。
发送请求
↡客户端按 HTTP 消息合同发送方法、头部、认证、幂等键和请求体，形成服务端可解释的输入。保存消息摘要、长度、request ID 和幂等键；发送中断时要区分服务端未收到、已收到但未处理和已处理但响应丢失。
服务处理
↡服务端校验请求、执行业务逻辑并更新数据状态，产生可观察的提交、拒绝或异步处理结果。服务端应记录 request ID、认证结果、事务状态、数据提交点和副作用。协议响应不是业务状态的唯一证据。
返回表示
↡服务端以状态码、响应头和表示内容返回处理结果或下一步状态，使客户端可以确认、查询或安全恢复。记录状态码、响应摘要、缓存语义、提交状态和客户端是否收到。超时后的恢复要用 request ID 查询，而不是盲目重复副作用请求。
最小可重放实现
request = build(uri, method, requestId, idempotencyKey)
connection = connect(timeout)
response = send(connection, request)
assertTrace(resource, connection, request, serviceState, representation)
assertTrue(resetAndRequest(request) == baselineTrace)这段草图只表达跨层请求合同，不复制书中叙事或代码。实际复核应保存 URI、request ID、连接阶段、消息摘要、认证、服务提交状态、响应和复位结果。
五步复核一次 Web 请求
1. 固定资源和请求身份
记录 URI、方法、参数、认证上下文、request ID 和幂等键；先预测正常路径的五个节点与业务结果。
Lab
超时、重试与重复副作用实验
一次只改变连接时序、响应可见性或幂等策略，观察服务状态和副作用计数。
连接、消息、服务提交和表示完整到达
requestId=R1 → connect → send → commit=1 → status=200 → received
判定
通过：协议表示与服务状态一致，副作用计数为一次
当前场景：基线请求；记录 URI、request ID、连接耗时、状态码、提交状态、重试和副作用计数。
正常、边界与故障证据
| 场景 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 资源可达、消息完整、服务提交成功 | 请求路径完整，表示与状态一致 | URI、连接、消息、提交、响应 |
| 边界 | 认证过期、超时、异步提交或部分响应 | 首个边界明确，客户端可查询或安全恢复 | request ID、状态码、超时、查询 |
| 故障 | 响应丢失后重试有副作用的请求 | 幂等键去重或明确未知状态，不能重复执行 | 服务日志、去重记录、数据状态 |
专属因果实验
先运行基线，预测资源、连接、请求、服务和表示五个节点；再一次只切换超时、认证或响应丢失。实验显示 request ID、连接耗时、状态码、提交状态、重试次数和副作用计数，避免用一条“成功箭头”掩盖远程不确定性。
Lab
超时、重试与重复副作用实验
一次只改变连接时序、响应可见性或幂等策略，观察服务状态和副作用计数。
连接、消息、服务提交和表示完整到达
requestId=R1 → connect → send → commit=1 → status=200 → received
判定
通过：协议表示与服务状态一致，副作用计数为一次
当前场景：基线请求；记录 URI、request ID、连接耗时、状态码、提交状态、重试和副作用计数。
故障诊断：从 request ID 沿边界找首错
- 核对资源定位：确认 URI、方法、参数、认证和 request ID 一致，排除客户端构造错误。
- 核对连接阶段：比较解析、握手、发送和接收时间，定位请求是否到达服务端。
- 核对服务提交：用 request ID 对照事务、数据和异步任务，区分未执行、执行中和已完成。
- 核对恢复策略：响应丢失时查询或带幂等键重试，清空测试数据后确认副作用只发生一次。
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 第3章 浪潮之巅的Web
由 URI、HTTP 消息、客户端、服务端和数据状态连接的远程协议系统。
- 定位资源
用 URI、方法和请求身份确定目标资源与动作的阶段。
- 建立连接
通过网络和安全握手建立通信路径并记录超时的阶段。
- 发送请求
按 HTTP 合同发送方法、头部、认证、幂等键和请求体的阶段。
- 服务处理
校验请求、执行业务并提交或拒绝数据状态的阶段。
- 返回表示
以状态码、头部和响应内容返回结果或下一步状态的阶段。
练习
练习
问题 1： 为什么收到 HTTP 200 仍不能直接证明业务操作已经完成？
问题 2： 超时后再次发送创建请求，怎样避免重复副作用？
问题 3： 如何区分请求未到达服务端和服务端已完成但响应丢失？
本页小结
第3章 浪潮之巅的Web的关键不是把请求画成一条顺滑箭头，而是沿定位资源、建立连接、发送请求、服务处理和返回表示保存跨层证据。完成标准是区分协议响应与业务提交，在超时、认证、响应丢失和重复副作用的首个边界修复，并用 request ID 与清空状态后的重放证明恢复安全。