围绕外部 API 假设进行设计：来自免费汇率 API 的教训

Source: Dev.to

项目概述

我开发并部署了一个名为 YenUp 的应用，它会比较今天的汇率与昨天的汇率，并根据结果发送通知。为了保持项目简洁且免费，我使用 Frankfurter API 作为数据源。

项目完成后我很高兴。但很快我注意到收到的通知有问题。

通知应该在今天的汇率优于昨天时才触发。为了端到端调试交付流水线，我添加了一个 notification=true 标记，即使汇率未变化也强制发送 Slack 消息。

我实际收到的通知如下：

Test Notification (forced). CAD/JPY: Yesterday 114.4300 -> Today 114.4300

起初，我怀疑是自己实现中的 bug。我检查了逻辑并再次核对了比较代码。最终，我意识到问题不在我的代码，而在我对 API 的假设上。

这种行为还被我的回退逻辑进一步放大。当特定日期的数据不可用（例如周末或每日更新之前），我的实现会回退到 latest 端点。于是，非工作日的汇率实际上会归并为同一个基础汇率。

我的收获

真正的问题不是 API 本身的行为，而是我对它的假设。我在设计逻辑时默认 “今天” 与 “昨天” 是日历天。然而，外部 API 常常根据自己的业务规则来定义这些概念，这些规则可能与产品使用数据的方式不一致。

接下来我会做什么

基于此，我正在考虑将比较逻辑改为使用 工作日 而不是日历天。由于在不同货币之间一致地定义工作日会增加额外的复杂性，这一点我还没有完全实现。

这个小 bug 让我重新审视了自己的假设，也改变了我对外部 API 与业务规则的思考方式。希望在后续项目中继续学习。