Процесс внесения изменений в API?

Я уже какое-то время управляю несколькими сайтами на платформе Discourse и использую ряд скриптов, которые напрямую взаимодействуют с API Discourse. Я заметил, что после обновлений периодически что-то перестаёт работать. В целом это нормально, если проблемы обнаруживаются сразу, но когда они проявляются не сразу, их становится сложно отследить, и это часто приводит к сбоям в рабочей среде, а не только в тестовых окружениях.

Например: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Недавно была удалена опция include_expired. К сожалению, поведение, при котором календарный API возвращал только неистёкшие события, было тем, на что я полагался, и это привело к сбоям нескольких процессов спустя некоторое время после обновления. В данном конкретном случае, если бы вызов с удалённым параметром приводил к ошибке, это хотя бы остановило проблему в моём скрипте :slight_smile:

Поэтому я хочу узнать: как пользователю, зависящему от Discourse, лучше всего выявлять подобные изменения в API до того, как они затронут мою инстанцию? Раньше я прибегал к созданию зеркала репозитория discourse-calendar и обновлял его реже, в удобное для себя время, чтобы избежать таких проблем. Теперь, когда он интегрирован, я отказался от этого подхода, и проблема снова дала о себе знать.

Я высоко ценю всю работу и улучшения, которые постоянно внедряются в Discourse, и меня устраивает ответ: «подпишитесь на Enterprise, и такие проблемы будут возникать реже», или «проведите больше тестов на вашей стороне». Однако я хотел бы узнать, есть ли другие варианты или подходы, о которых я мог не знать.

Спасибо.

Я столкнулся с аналогичной проблемой, но выбрал другой путь. Вместо прямого обращения к конечным точкам API календаря мой импортер формирует BBCode-тег [event] и публикует его в Discourse, позволяя плагину обработать его так, будто событие было создано вручную сотрудником. Таким образом я избегаю зависимости от временных параметров запроса, таких как include_expired, и получаю более стабильный контракт — обычные посты и BBCode вряд ли изменятся без предупреждения.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Встреча для обсуждения RESTful API Discourse
[/event]

Минус этого подхода — дополнительные усилия с моей стороны: мне пришлось написать форматировщик, который преобразует данные ICS в корректно экранированные теги [event], обрабатывает события на весь день и события с указанием времени и так далее. Однако на практике этот метод оказался гораздо более устойчивым к обновлениям. Он не отменяет необходимости получать уведомления о устаревании со стороны провайдера (я всё ещё хотел бы, чтобы API быстро сообщали об ошибках или хотя бы предупреждали об удалении опций), но значительно снизил риск молчаливого сбоя моих скриптов.

Реализация собственного API-эндпоинта через плагин не должна быть слишком сложной. Затем вы сможете использовать стандартный подход RSpec для набора тестов, который можно запускать на тестовом сайте перед обновлениями.