API 更改流程？

支持
1

我运行 Discourse 站点已经有一段时间了，并且有许多脚本直接与 Discourse 的 API 交互。我发现升级后，这些脚本有时会停止工作。通常情况下，如果问题能立即被发现，那还好，但如果过一段时间才显现出来，就很难追踪，并且经常导致生产环境出现问题，而不是开发实例。

例如：Recurring events in Upcoming Events calendar fail to handle daylight saving change

最近移除了 include_expired 选项。不幸的是，我依赖的日历 API 只返回未过期的事件的行为，导致在升级后的一段时间内，许多进程崩溃。对于这个特定的例子，如果调用者指定了现在已移除的参数，至少可以阻止我的脚本出现问题 :slight_smile:

所以我想知道，作为 Discourse 的下游用户，在这些 API 更改影响我的实例之前识别它们的最佳方法是什么？以前，我曾镜像 discourse-calendar 仓库，并较少地在自己的时间升级它以避免这些问题。现在它已集成，我决定放弃这种方法，又一次遇到了麻烦。

我感谢 Discourse 不断进行的改进和工作，如果答案是“注册企业版，这些问题会减少”，或者你们能在你们那边增加更多测试，我都可以接受，但我想看看是否还有其他我不知道的选项或方法。

谢谢。

4 个赞
2

我遇到了同样的故障，但我走了另一条路。我的导入器不直接使用日历 API 端点，而是构建 [event] BBCode 并将其发布到 Discourse，让插件像管理员手动创建事件一样解析它。这样，我就避免了依赖 include_expired 等瞬时查询参数，并获得了更稳定的契约——纯文本帖子和 BBCode 不太可能在未经通知的情况下更改。

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
讨论 Discourse RESTful API 的会议
[/event]

权衡是我的工作量增加了：我不得不编写一个格式化程序，将 ICS 数据转换为正确转义的 [event] 标签，处理全天事件或定时事件等。但实际上，这种方法在升级过程中一直更具弹性。它并没有消除对上游弃用通知的需求（我仍然希望 API 在选项被移除时能快速失败或至少发出警告），但它降低了我的脚本无声中断的风险。

4 个赞
3

通过插件实现自己的 API 端点应该不难。然后，您可以使用常规的 RSpec 方法来编写测试套件，您可以在更新前在暂存站点上调用它。

1 个赞