题目重点:比较请求语义,说明 URL、消息体与 HTTPS,不靠长度传言选择方法。
题意与假设
这道练习题保留了面经中值得训练的核心约束,并将需要澄清的条件单独列出。现场拿到变体时,先和面试官确认这些条件。
- 按 HTTP 标准语义讨论。接口业务合同和客户端支持也需共同确定。
解题路线
- GET 请求资源表示,语义安全且幂等;安全指客户端请求不意图改变服务端业务状态,不表示完全没有日志等副作用。
- POST 请求目标资源按自身语义处理表示,通常不保证幂等。支付等操作可用业务幂等键防止重复副作用,这不改变方法本身的通用保证。
- GET 参数通常在 query;GET body 没有普遍定义的语义,可能被中间层拒绝。POST 常用 body,但 URL 仍可带 query。
- 两者都需 HTTPS 保护传输;POST 并不会自动保密,服务端/代理日志仍需脱敏。缓存依据方法、状态与显式指令,POST 不能简单说绝对不可缓存。
手动走一遍
GET /orders/7 读取订单;POST /orders 创建订单,超时后客户端用相同幂等键重试,服务端返回同一结果。不能把“读取后标已读”的隐式业务修改塞进必须安全的 GET,预取或重试可能触发意外操作。
规模与取舍
URL/body 限制取决于客户端、代理与服务器,标准没有统一“GET只能2KB”保证。数据大小与重试成本需实测。
易错点与追问
容易失分的边界
- POST 天然安全且不被记录。
- 幂等意味着响应每次字节相同。
- 缓存是 GET/POST 的绝对二分。
继续深挖
- 条件请求如何减少传输?
- 幂等键相同但 payload 不同如何处理?
技术参考
- HTTP Semantics RFC 9110:公开技术语义参考。
