为什么大多数人使用拦截器在改造中添加身份验证标头？

Question

• Stack Overflow Q&A
• Medium Blog post
• More blog post

其中的每一个都在拦截器阶段添加身份验证，而不是对Retrofit使用@Header或@Headers注释。有什么原因吗？因为有时您将拥有不需要身份验证的API（例如，如果您具有后端系统状态终结点），即使它不会破坏任何内容，它仍然感觉没有必要并且也被稍微隐藏了。

谢谢！

Answer 1

  

有什么原因吗？

在许多情况下，这比将身份验证标头作为参数传递给每个需要该标头的每个Retrofit方法更为方便。

例如，假设我们正在与一个具有123,456,789个端点的Web服务接口，我们需要对其进行命中。根据您的计划，我们需要：

• 将@Header注释的参数添加到Retrofit API接口上的123,456,789方法中
• 安排将该参数传递给我们对这123,456,789个方法的所有调用

使用拦截器，我们添加了一个拦截器，它涵盖了所有这些方法。

  

因为有时您将拥有不需要身份验证的API（例如，如果您具有后端系统状态端点）

假设这些端点中的789个不需要身份验证。其余的123,456,000做。根据您的计划，我们需要：

• 将@Header注释的参数添加到我们Retrofit API接口上的123,456,000个方法中
• 安排将该参数传递给我们对这123,456,000个方法的所有调用

使用拦截器，我们需要一个拦截器来处理所有拦截器。该拦截器可以使用以下白名单来确定哪些端点可以跳过标头：

• 路径正则表达式
• 路径段匹配
• 全路径匹配
• 随便

---

很显然，我在这里开玩笑，因为很少有Web服务具有123,456,789个端点。

但是，在某些收支平衡点，拥有拦截器比处理@Header参数要简单。收支平衡点在哪里取决于开发团队。