ureq 3.x 版本中响应URI获取功能的演进

在 HTTP 客户端库 ureq 从 2.x 升级到 3.x 的过程中，一个值得注意的变化是关于如何获取最终响应 URI 的功能演进。这个功能在处理 HTTP 重定向时尤为重要，它允许开发者追踪请求最终到达的 URL。

功能背景

在 HTTP 请求过程中，服务器可能会返回 3xx 状态码进行重定向。客户端库会自动跟随这些重定向，最终到达目标地址。对于开发者而言，了解请求最终到达的 URI 对于调试、日志记录和某些业务逻辑都至关重要。

ureq 2.x 的实现方式

在 ureq 2.x 版本中，Response 结构体提供了一个 get_url 方法。这个方法简单直接，开发者可以轻松获取到经过所有重定向后的最终 URI。

3.x 版本的架构变化

随着 ureq 3.x 采用了 http crate 作为底层实现，原有的 get_url 方法不再可用。这是因为 http crate 的 Response 对象设计上不包含请求 URI 信息。这种设计决策可能是出于最小化内存占用和简化核心结构的考虑。

解决方案探索

社区提出了使用 http crate 的 Extension 特性来恢复这一功能的建议。Extension 机制允许在 HTTP 组件之间传递额外的、类型安全的元数据。这正是 reqwest 等其他流行 HTTP 客户端库采用的解决方案。

技术实现细节

通过 Extension 机制，可以在处理重定向时将最终 URI 存储在 Response 的扩展数据中。这种方式既保持了与 http crate 的兼容性，又恢复了开发者需要的重要功能。实现上需要：

1. 在请求处理过程中跟踪重定向链
2. 将最终 URI 存储在 Response 的扩展中
3. 提供便捷的访问方法供开发者使用

对开发者的影响

这一功能的恢复意味着开发者可以平滑地从 ureq 2.x 迁移到 3.x 版本，而不必重写与最终 URI 相关的代码。对于新用户来说，获取重定向后 URI 的 API 保持了直观易用的特点。

总结

ureq 3.x 通过合理利用 http crate 的扩展机制，既保持了代码的现代化和高效性，又维护了重要的开发者体验。这种演进展示了如何在底层架构变化的同时，通过适当的设计决策保持用户友好的 API 接口。