Processus de changement d'API ?

Je gère plusieurs sites Discourse depuis un certain temps et j’ai un certain nombre de scripts qui interagissent directement avec certaines des API de Discourse. Je constate que périodiquement, les choses cessent de fonctionner après une mise à niveau. En général, cela ne pose pas de problème si les problèmes sont détectables immédiatement, mais lorsqu’ils n’apparaissent que plus tard, il devient difficile de les résoudre et cela entraîne souvent des problèmes de production plutôt que des problèmes sur les instances de développement.

Par exemple : Recurring events in Upcoming Events calendar fail to handle daylight saving change

Récemment, l’option include_expired a été supprimée. Malheureusement, le comportement consistant à ne retourner que les événements non expirés de l’API du calendrier était quelque chose sur lequel je comptais, et cela a provoqué l’échec d’un certain nombre de processus à une date ultérieure, après la mise à niveau. Pour cet exemple particulier, échouer si un appelant spécifiait le paramètre maintenant supprimé aurait au moins arrêté le problème dans mon script particulier :slight_smile:

Je me demande donc, en tant qu’utilisateur en aval de Discourse, quelle est la meilleure façon d’identifier les changements d’API comme ceux-ci avant qu’ils n’affectent mon instance ? Auparavant, j’ai eu recours à la duplication du dépôt discourse-calendar et à sa mise à niveau moins fréquemment de mon côté pour éviter ces problèmes. Maintenant qu’il est intégré, j’ai décidé d’abandonner cette approche et je me fais à nouveau avoir.

J’apprécie tout le travail et les améliorations constants apportés à Discourse, et cela me convient si la réponse est “inscrivez-vous à l’offre entreprise et ces choses se produiront moins fréquemment”, ou si vous ajoutez plus de tests de votre côté, mais je voulais voir s’il existe peut-être d’autres options ou approches que j’ignore.

Merci.

4 « J'aime »

J’ai rencontré le même type de problème, mais j’ai suivi une voie différente. Au lieu de consommer directement les points de terminaison de l’API du calendrier, mon importateur crée du BBCode [event] et le publie dans Discourse, laissant le plugin l’analyser comme si un utilisateur du personnel avait créé l’événement manuellement. De cette façon, j’évite de dépendre de paramètres de requête transitoires comme include_expired, et j’obtiens un contrat plus stable — les publications simples et le BBCode sont peu susceptibles de changer sans préavis.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Rencontre pour discuter de l'API RESTful de Discourse
[/event]

Le compromis est plus de travail de mon côté : j’ai dû écrire un formateur qui convertit les données ICS en balises [event] correctement échappées, gère les événements de toute la journée par rapport aux événements programmés, etc. Mais en pratique, cette approche s’est avérée beaucoup plus résiliente aux mises à niveau. Elle ne supprime pas le besoin d’avis de dépréciation en amont (j’aimerais toujours que les API échouent rapidement ou au moins avertissent lorsque les options sont supprimées), mais elle a réduit le risque que mes scripts se cassent silencieusement.

4 « J'aime »

Implémenter votre propre point de terminaison d’API via un plugin ne devrait pas être si difficile. Vous pouvez ensuite utiliser la manière habituelle de RSpec pour une suite de tests, que vous pouvez appeler sur un site de staging avant les mises à jour.

1 « J'aime »