Parece que poderiam haver algumas melhorias na forma como as atribuições de tags em tópicos são expostas por meio da API. Especificamente, a capacidade de consultar tags recém-adicionadas em tópicos. Meu caso de uso específico é utilizar o sistema de tags do Discourse para indicar que algum tópico deve ser exportado para outro sistema (um gerenciador de tarefas, por exemplo), e estou planejando usar a Integromat para fazer isso. Mas isso poderia ser aplicado igualmente a qualquer sistema que consulte a API para determinar, por exemplo, se uma tag “Criar Tarefa” foi adicionada a um tópico e, em seguida, agir com base nessa informação.
Minha compreensão é que a API atual não permite isso facilmente. Existe uma solução alternativa com webhooks, mas, a menos que eu esteja enganado, uma chamada direta à API seria mais limpa e simples.
Obrigado por considerar isso! Espero ter colocado isso no lugar certo.
Adicionar uma tag em um tópico acionará a classe de webhook topic, que você pode monitorar para acompanhar qualquer tag recém-adicionada em seus tópicos. Você pode até mesmo filtrá-la para uma tag específica na interface do Discourse, para manter o número de eventos baixo.
Obrigado pela resposta rápida! Então a “solução alternativa” que o Integromat sugere é realmente a maneira prevista de lidar com isso?
Infelizmente, não sou muito familiarizado com APIs versus webhooks, etc., mas estou pensando especificamente na integração que o Fibery tem com o Discourse. Na verdade, ele espelha totalmente o conteúdo do Discourse, mas em um sistema que permite interligação arbitrária de dados (por exemplo, tópicos, usuários, etc.) para gerenciamento de projetos e feedback em nível superior. Pelo que entendi, eles usam a API para essa integração:
Então, se eles quisessem dar suporte a tags em sua integração (o que atualmente não fazem), incluindo a detecção de adição/remoção de tags, seria possível com a API atual? Se não, isso sugere alguma utilidade ainda não vista para adicionar mais profundidade ao suporte a tags da API?
Novamente, reconheço que posso estar fazendo perguntas óbvias por ignorância. Talvez seja difícil ou excessivamente trabalhoso expor isso na API, ou simplesmente não faça sentido por algum motivo. Mas espero que seja algo fácil de esclarecer.
Uma chamada de API permite que um serviço externo acesse o Discourse sempre que desejar para extrair dados.
No entanto, se esse serviço quiser reagir a eventos no Discourse, precisaria verificar periodicamente por alterações (polling), o que é desperdício ou impraticável se houver muitas “coisas” para monitorar/verificar.
Os webhooks permitem que o Discourse dê um leve empurrão nesse serviço externo sempre que um novo evento ocorrer, para que ele possa fazer o seu trabalho apenas quando houver algo a fazer. O serviço pode confiar nas informações do payload do webhook, se forem suficientes, ou usá-las para acionar chamadas de API adicionais para executar a tarefa necessária. Assim, a API e o sistema de webhooks são complementares.
Excelente, isso é muito útil. Então, digamos que você esteja espelhando o Discourse para um sistema externo (Fibery). Se entendi corretamente, seria apropriado usar a API para coletar inicialmente todos os dados dos tópicos, etc. Mas, se você quisesse manter esses dados atualizados ao longo do tempo, por exemplo, para alterações de Categoria ou Tag, você usaria Webhooks para ficar informado sobre essas mudanças, certo? Se sim, e quanto a obter dados para tópicos totalmente novos? Através da API ou do Webhook? Talvez colocando de outra forma, faz sentido usar a API apenas para uma extração única para popular um espelho e, em seguida, usar Webhooks continuamente para mantê-lo atualizado em tudo? Ou é uma combinação dos dois e, se for, como essa combinação funciona?
Gostaria muito de fechar o ciclo sobre este tópico e ter certeza de que entendo completamente como isso deve funcionar. Estou trabalhando com a equipe do Fibery na esperança de que eles também implementem isso. Portanto, se você puder responder às minhas perguntas restantes, isso seria muito apreciado.
