Ich bin auf die gleiche Art von Problemen gestoßen, aber ich bin einen anderen Weg gegangen. Anstatt die Kalender-API-Endpunkte direkt zu nutzen, erstellt mein Importer [event] BBCode und postet ihn in Discourse, sodass das Plugin ihn so parst, als hätte ein Mitarbeiter das Ereignis von Hand erstellt. Auf diese Weise vermeide ich die Abhängigkeit von transienten Abfrageparametern wie include_expired und erhalte einen stabileren Vertrag – einfache Posts und BBCode werden sich wahrscheinlich nicht ohne Vorankündigung ändern.
[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Treffen zur Besprechung der Discourse RESTful API
[/event]
Der Kompromiss ist mehr Arbeit meinerseits: Ich musste einen Formatter schreiben, der ICS-Daten in ordnungsgemäß maskierte [event]-Tags umwandelt, ganztägige oder zeitlich festgelegte Ereignisse behandelt und so weiter. Aber in der Praxis war dieser Ansatz bei Upgrades weitaus widerstandsfähiger. Er beseitigt nicht die Notwendigkeit von Upstream-Deprecation-Hinweisen (ich möchte immer noch, dass APIs schnell fehlschlagen oder zumindest warnen, wenn Optionen entfernt werden), aber er hat das Risiko verringert, dass meine Skripte stillschweigend kaputtgehen.