Processo di modifica dell'API?

[dubwoc]

Gestisco alcuni siti Discourse da un po’ di tempo e ho una serie di script che interagiscono direttamente con alcune delle API di Discourse e scopro che periodicamente le cose smettono di funzionare dopo un aggiornamento. Generalmente questo va bene se le cose sono rilevabili immediatamente, ma quando non si manifestano per un po’ di tempo diventa difficile da risolvere e spesso si traduce in problemi di produzione piuttosto che in istanze di sviluppo.

Ad esempio: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Recentemente è stata rimossa l’opzione include_expired, sfortunatamente il comportamento di restituire solo gli eventi dal calendario API che non sono scaduti era qualcosa su cui facevo affidamento e ha causato l’esplosione di numerosi processi in un secondo momento dopo l’aggiornamento. Per questo particolare esempio, il fallimento se un chiamante specificasse il parametro ora rimosso avrebbe almeno fermato il problema nel mio particolare script

Quindi, quello che mi chiedo è, come utente a valle di Discourse, qual è il modo migliore per identificare modifiche alle API come questa prima che raggiungano la mia istanza? In precedenza, mi sono limitato a rispecchiare il repository discourse-calendar e ad aggiornarlo meno frequentemente a mio tempo per evitare questi problemi, ora che è integrato ho deciso di abbandonare quell’approccio e mi sto mordendo di nuovo.

Apprezzo tutto il lavoro e i miglioramenti che Discourse subisce costantemente e va bene se la risposta è “iscriviti all’enterprise e queste cose accadranno meno frequentemente”, o aggiungi più test da parte tua, ma volevo vedere se forse ci sono altre opzioni o approcci di cui non sono a conoscenza.

Grazie.

[Ethsim2 (Ethan)]

Ho riscontrato lo stesso tipo di problema, ma ho seguito un percorso diverso. Invece di utilizzare direttamente gli endpoint dell’API del calendario, il mio importatore crea BBCode [event] e lo pubblica in Discourse, lasciando che il plugin lo analizzi come se un utente dello staff avesse creato l’evento manualmente. In questo modo evito di dipendere da parametri di query transitori come include_expired e ottengo un contratto più stabile: post semplici e BBCode difficilmente cambieranno senza preavviso.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Incontro per discutere l'API RESTful di Discourse
[/event]

Il compromesso è più lavoro da parte mia: ho dovuto scrivere un formattatore che converte i dati ICS in tag [event] correttamente escapati, gestisce eventi di un’intera giornata o a orari specifici, e così via. Ma in pratica questo approccio è stato molto più resiliente agli aggiornamenti. Non elimina la necessità di avvisi di deprecazione upstream (vorrei ancora che le API fallissero rapidamente o almeno avvisassero quando le opzioni vengono rimosse), tuttavia ha ridotto il rischio che i miei script si rompessero silenziosamente.

[thoka (Thomas Kalka)]

Implementare un endpoint API personalizzato tramite un plugin non dovrebbe essere troppo difficile. Quindi è possibile utilizzare il consueto metodo RSpec per una suite di test, che è possibile richiamare su un sito di staging prima degli aggiornamenti.