תהליך שינוי API?

I have been running a few discourse sites for some time now and I have a number of scripts that interact directly with some of Discourse’s APIs and I find that periodically things just stop working after an upgrade. Generally this is fine if the things are detectable immediately but when they don’t show up for a bit of time it becomes difficult to chase things down and often results in production issues rather than dev instances.

For example: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Recently removed the include_expired option, unfortunately the behavior of only having events returned from the calendar API that are not expired was something I relied on and it caused a number of processes to blow up at a later date after upgrading. For this particular example failing if a caller specified the now removed parameter would have at least stopped the issue in my particular script :slight_smile:

So what I am wondering is as a downstream user of discourse what is the best way to identify API changes like this before they hit my instance? Previously I resorted to mirroring the discourse-calendar repo and upgrading it less frequently on my own time to avoid these problems, now that it is integrated I decided to drop that approach and I am being bit again.

I appreciate all the work and improvement discourse constantly goes under and I am fine if the answer is “sign up for enterprise and these things will happen less frequently,” or add more testing on your end but I wanted to see if maybe there are other options or approaches I am unaware of.

Thank you.

4 לייקים

נתקלתי באותו סוג של תקלה, אבל הלכתי בדרך אחרת. במקום לצרוך את נקודות הקצה של ה-API של לוח השנה ישירות, הייבואן שלי בונה BBCode של [event] ומפרסם אותו ל-Discourse, מה שמאפשר לפלאגין לנתח אותו כאילו משתמש צוות יצר את האירוע ידנית. כך אני נמנע מהסתמכות על פרמטרים חולפים של שאילתות כמו include_expired, ואני מקבל חוזה יציב יותר - פוסטים רגילים ו-BBCode לא צפויים להשתנות ללא הודעה מוקדמת.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Meet to discuss Discourse RESTful API
[/event]

הפשרה היא יותר עבודה מצדי: הייתי צריך לכתוב פורמטר שממיר נתוני ICS לתגיות [event] שעברו בריחה כראוי, מטפל באירועים של כל היום לעומת אירועים מתוזמנים, וכן הלאה. אבל בפועל הגישה הזו הייתה הרבה יותר עמידה לאורך שדרוגים. היא לא מבטלת את הצורך בהודעות על הפסקת שימוש (עדיין הייתי רוצה ש-APIs ייכשלו במהירות או לפחות יזהירו כאשר אפשרויות מוסרות), אך היא הפחיתה את הסיכון שהסקריפטים שלי יישברו בשקט.

4 לייקים

הטמעת נקודת קצה משלך באמצעות תוסף לא אמורה להיות קשה במיוחד. אז תוכל להשתמש בדרך ה-RSpec הרגילה עבור מערך בדיקות, שתוכל להפעיל באתר staging לפני עדכונים.

לייק 1