测验：同步 REST 对接

为什么同步集成中的连接超时（connect timeout）应设得较短（1～3 秒）？

• 避免对方服务器宕机时长期占用我方线程
• 节省网络带宽
• 减少响应数据大小
• 跳过 TLS 握手

发送订单时发生超时，这一情况的本质问题是什么？

• 线路带宽不足，报文未能及时全部发送
• 无法判断对方没收到请求，还是已处理但响应丢失
• 传输中途断开，请求数据可能损坏后到达
• 连接保持过久，认证令牌可能已经过期

以下哪项不是发送前由我方验证数据的实际理由？

• 减少往返时间和返工
• 避免我方错误堆积在对方系统日志中
• 提升对方系统响应速度
• 防止大批量作业中数千条记录同时失败

为什么集成日志要记录追踪 ID（trace_id），并同时通过请求头发送？

• 有请求标识后可过滤重复日志，缩小日志文件
• 发生故障时可与对方系统日志对照，找到同一个请求
• 把请求头中的值作为密钥加密和解密报文
• 同一追踪 ID 出现两次时，接收方可直接视为重复并阻止

需要向对方系统发送 10 万条订单时，为什么不能逐条调用同步 REST？

• REST 规范限制了单次可发送的报文大小
• 即使每条只需 100ms，总耗时也达数小时，中断后还无法知道处理到哪里
• JSON 承载相同数据时远大于定长文件
• HTTP 有单连接吞吐上限，原则上不用于批量传输

设计批量 API（一次请求 100 条）时，定义文档必须明确什么？

• 请求头顺序和必需请求头的精确匹配规则
• 为缩小报文而规定 JSON 缩进和空格删除规则
• 部分失败时是整体回滚，还是保留成功记录并只返回失败记录
• 支持的 HTTP 版本和连接复用方式