Sembra che ci possano essere alcuni miglioramenti su come le assegnazioni di tag ai topic sono esposte tramite l’API. Nello specifico, la possibilità di interrogare l’API per ottenere i tag appena aggiunti ai topic. Il mio caso d’uso particolare è utilizzare i tag in Discourse per indicare che un topic dovrebbe essere esportato in un altro sistema (ad esempio, un task manager), e ho intenzione di utilizzare Integromat per farlo. Ma questo potrebbe applicarsi facilmente a qualsiasi sistema che interroga l’API per determinare se, ad esempio, è stato aggiunto un tag “Crea attività” a un topic e poi agire di conseguenza.
La mia comprensione è che l’API attuale non lo permetta facilmente. Esiste un workaround con i webhook, ma a meno che non mi sbagli, una chiamata API diretta sarebbe più pulita e semplice.
Grazie per aver preso in considerazione la richiesta! Spero di aver scritto nel posto giusto.
Aggiungere un tag a un topic attiverà la classe webhook topic, che puoi ascoltare per monitorare i nuovi tag aggiunti nei tuoi topic. Puoi persino filtrarlo per un tag specifico nell’interfaccia utente di Discourse, per mantenere basso il numero di eventi.
Grazie per la risposta veloce! Quindi il “workaround” suggerito da Integromat è davvero il modo previsto per gestire questa situazione?
Purtroppo non sono molto esperto di API rispetto ai webhook, ecc., ma sto pensando in particolare all’integrazione che Fibery ha con Discourse. In realtà, essa specchia completamente i contenuti di Discourse, ma in un sistema che consente collegamenti arbitrari tra i dati (ad esempio topic, utenti, ecc.) per una gestione più avanzata dei progetti e del feedback. Per quanto ne so, utilizzano l’API per questa integrazione:
Quindi, se loro volessero supportare i tag nella loro integrazione (cosa che attualmente non fanno), inclusa l’individuazione dell’aggiunta o rimozione di tag, sarebbe possibile con l’API attuale? Se no, ciò suggerisce qualche utilità ancora non vista per approfondire il supporto dei tag nell’API?
Di nuovo, riconosco che potrei porre domande ovvie per ignoranza. Forse è difficile o eccessivamente oneroso esporre queste funzionalità nell’API, oppure semplicemente non ha senso per qualche motivo. Ma spero sia qualcosa di abbastanza semplice da chiarire.
Una chiamata API consente a un servizio esterno di contattare Discourse quando vuole per estrarre dati da Discourse.
Tuttavia, se quel servizio vuole reagire agli eventi in Discourse, dovrebbe interrogare periodicamente le modifiche, il che è uno spreco o poco pratico se ci sono molte “cose” da monitorare/interrogare.
I webhook permettono a Discourse di dare un leggero stimolo a questo servizio esterno ogni volta che si verifica un nuovo evento, in modo che il servizio esterno possa fare la sua cosa solo quando c’è qualcosa da fare. Il servizio può fare affidamento sulle informazioni del payload del webhook, se sufficienti, o utilizzarle per attivare chiamate API aggiuntive per eseguire il compito necessario. Quindi l’API e il sistema dei webhook sono complementari.
Ottimo, è molto utile. Quindi, supponiamo che tu stia replicando Discourse in questo sistema esterno (Fibery). Se ho capito bene, sarebbe appropriato utilizzare l’API per raccogliere inizialmente tutti i dati dei topic, ecc. Ma se volessi mantenere aggiornati quei dati nel tempo, ad esempio per modifiche alle categorie o ai tag, dovresti usare i webhook per essere informato di tali cambiamenti, giusto? In tal caso, come si ottengono i dati per topic completamente nuovi? Attraverso l’API o i webhook? Forse detto in altro modo: ha senso usare l’API solo per un’estrazione iniziale per popolare un mirror, e poi i webhook in modo continuativo per mantenerlo aggiornato su tutto? Oppure è una combinazione dei due, e in tal caso, come funziona questa combinazione?
Mi piacerebbe molto chiudere il cerchio su questo argomento e sapere di aver compreso appieno come dovrebbe funzionare. Sto lavorando con il team di Fibery nella speranza che possano implementarlo anch’essi. Quindi, se aveste la possibilità di rispondere alle mie domande rimanenti, ve ne sarei molto grato.