TikTok HTTP Query vs Header：资源选择、元数据与缓存

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 训练HTTP API，query参与URL，header携带请求元数据；服务具体认证和缓存合同另定。

解题路线

1. query通常描述资源筛选/分页/排序，例如?status=open&page=2；header常表达认证、内容协商、追踪或条件请求。两者不是简单“都能传所以随便”。
2. URL会出现在地址、历史、访问日志/分析等位置，敏感token不宜随意放query。header同样会被服务/代理日志读到，需要TLS、脱敏和访问控制，不天然保密。
3. 缓存常以URL及规则作key，query改变可能区分缓存项；header影响表示时需适当Vary/缓存key配置，否则不同用户或语言可能错命中。认证数据不能只靠Vary解决全部安全。
4. URL编码和重复query key需定义解析政策，长复杂提交通常body更合适；header有字段语法与大小限制，不能无限塞大JSON。服务和代理限制依环境。
5. 签名/幂等与条件请求适合明确标准或自定义header合同，业务过滤仍保资源语义；客户端构造/服务端校验应统一，不因传header便跳验证。
6. 测试代理转发、大小/编码、重复参数、缓存隔离和日志脱敏；不要用“query明文header加密”错误对比，HTTPS对两者传输均加密但端点仍可读取。

手动走一遍

GET /orders?status=open用于过滤，Authorization携凭证，Accept-Language影响语言时缓存需考虑该header。把用户token塞URL可能进日志，放header仍需脱敏。

规模与取舍

解析成本按请求字节，缓存key维度提高命中隔离也可能降低命中率；限制长度和基数，不能把位置选择当性能常量保证。

易错点与追问

容易失分的边界

• header自动加密而query不加密。
• 过滤参数放任意位置不定义缓存。
• 敏感凭证出日志未考虑。

继续深挖

• query重复key如何处理？
• Vary怎样影响缓存？
• 签名时canonical请求怎么定义？