A API REST é sempre adequada à indústria? Quando é preferível optar por filas, brokers e comunicação orientada por eventos?

A pergunta sobre se uma REST API é adequada para a indústria já não se limita a discutir o estilo de integração preferido; hoje, trata-se de decidir onde o projeto vai assumir custos, atrasos e responsabilidade operacional. Em ambiente industrial, a interface de comunicação deixa rapidamente de ser apenas uma “camada técnica” e passa a influenciar a continuidade do processo, a reprodutibilidade das operações, a possibilidade de auditoria e a forma de responder a falhas. O REST funciona bem quando se espera uma chamada simples, uma resposta inequívoca e um controlo claro sobre o estado do pedido. O problema começa quando o sistema tem de continuar a funcionar apesar da indisponibilidade temporária de um dos intervenientes, quando as mensagens têm de ser entregues com confirmação, ou quando um único evento deve produzir efeitos em várias áreas independentes. Nesses casos, a escolha entre um pedido síncrono e uma fila, um broker e comunicação orientada a eventos deixa de ser tecnicamente indiferente.

Isto é particularmente relevante agora, porque cada vez mais projetos industriais ligam o controlo, a manutenção, os sistemas da qualidade, o reporte da produção e serviços externos numa única cadeia de dependências. Se a arquitetura assentar exclusivamente em chamadas síncronas, a equipa recebe muitas vezes um sistema aparentemente simples, mas frágil quando aumenta o número de integrações, quando a rede é instável ou quando é exigido um rasto rigoroso dos eventos. O custo desta decisão não se revela na fase de demonstração das funcionalidades, mas mais tarde: no bloqueio de processos por um componente indisponível, na dificuldade em reconstruir a sequência de um incidente, na reconciliação manual de estados entre sistemas e em discussões sobre se a operação foi efetivamente executada ou apenas solicitada. Para o dono do produto e para o gestor de projeto, o critério prático é simples: é preciso decidir se determinada troca de dados tem a natureza de “pergunta–resposta aqui e agora” ou antes de “registar um facto e garantir o seu tratamento posterior mesmo em caso de perturbações”. Desta resposta depende não só a tecnologia, mas também o modelo de responsabilidade entre equipas.

Na prática, isto vê-se bem em sistemas de máquinas em que uma única ação do operador ou um único evento de processo tem de ser registado, transmitido e confirmado em vários pontos. Se a aplicação de supervisão enviar um pedido síncrono para serviços sucessivos e ficar à espera do conjunto completo de respostas, um problema momentâneo num dos elementos pode parar toda a sequência, embora parte dos efeitos de negócio devesse ocorrer de forma independente. Por outro lado, um broker ou uma fila permitem separar o momento de receção da informação do momento do seu processamento, preservar o rasto do evento e controlar com mais facilidade a repetição após erro. Isto não significa que a comunicação orientada a eventos seja sempre melhor: se for necessária uma decisão imediata que bloqueie o movimento posterior da máquina, ou se o operador tiver de receber de imediato uma resposta vinculativa, um modelo assíncrono sem estados intermédios bem concebidos pode aumentar a incerteza. Por isso, logo no início do projeto, vale a pena medir não apenas o tempo de resposta, mas também o número de mensagens perdidas ou duplicadas, o tempo necessário para reconciliar estados divergentes e a possibilidade de reconstruir a sequência de eventos após um incidente.

Este tema cruza-se naturalmente com a avaliação do risco em projetos industriais, porque a escolha da forma de comunicação influencia a consequência do erro, a capacidade de detetar anomalias e a possibilidade de implementar medidas eficazes de redução do risco. Se pela interface passam funções cuja execução incorreta pode conduzir a um arranque não intencional, a uma alteração perigosa de estado ou à perda de controlo sobre a energia, o tema deixa de ser exclusivamente informático e passa para o domínio da conceção do sistema da máquina e da avaliação das medidas de proteção. É também aqui que surge o limite a partir do qual é necessário considerar temas relacionados, incluindo a proteção contra o arranque inesperado e a avaliação prática do risco de acordo com a metodologia adotada. Por outras palavras: a decisão entre REST, fila ou broker não deve ser tomada depois da demo da integração, mas sim quando a equipa consegue identificar a consequência de uma mensagem incorreta ou atrasada para o processo, a segurança e a rastreabilidade das operações.

Onde o custo ou o risco mais frequentemente aumentam

A maioria das decisões erradas não resulta da escolha da “tecnologia errada”, mas sim de atribuir à REST API tarefas para as quais ela não foi concebida. Na indústria, o custo aumenta quando uma interface de pedido–resposta tem de suportar uma comunicação sensível à indisponibilidade temporária, à ordem dos eventos ou à necessidade de confirmação fiável da execução. Se o sistema apenas tiver de ler o estado atual do equipamento ou receber uma instrução cuja ausência possa ser facilmente detetada e repetida sem efeitos secundários, o REST pode ser suficiente. No entanto, se o resultado depender de a mensagem chegar exatamente uma vez, na ordem correta e com possibilidade de reconstruir o histórico após um incidente, o custo de contornar as limitações do REST ultrapassa rapidamente a aparente simplicidade da implementação. Na prática, isto significa lógica adicional de repetição, mecanismos próprios de buffering, reconciliação de estados divergentes e maior dificuldade em apurar responsabilidades quando o equipamento executou a operação mais tarde do que o esperado ou a executou duas vezes.

Na fase de projeto, o problema costuma parecer inofensivo: a equipa parte do princípio de que a rede é estável, os serviços estão sempre disponíveis e o estado em ambos os lados da integração é inequívoco. Em ambiente industrial, estes pressupostos raramente se mantêm por muito tempo. Surgem falhas de comunicação, reinícios de equipamentos, atualizações de sistemas intermédios e, por vezes, simplesmente sobrecarga nas horas de mudança de turno. Nessa altura, uma arquitetura assente exclusivamente em chamadas síncronas começa a transferir o risco para as aplicações e para os operadores. O custo do projeto aumenta não só devido a correções de software, mas também por causa de testes de reprodução, procedimentos operacionais adicionais e discussões sobre qual das partes “deveria saber” que o pedido não foi executado. O critério prático de decisão é simples: se a indisponibilidade do destinatário não puder parar o emissor e a mensagem tiver de ser armazenada em segurança para ser tratada mais tarde, é necessário considerar seriamente uma fila, um broker ou comunicação orientada a eventos em vez de REST puro.

Um bom exemplo é a integração de um sistema de supervisão com uma linha em que um sistema ordena a alteração da receita, e vários outros têm de receber essa alteração, confirmá-la e aplicá-la no momento certo do ciclo. Com REST, é fácil criar uma chamada do tipo “definir parâmetros”, mas é mais difícil garantir que todos os elementos envolvidos receberam a mesma informação, que uma mensagem mais antiga não sobrescreve uma mais recente e que, após uma falha, será possível determinar quem viu que instrução. Um broker de eventos ou uma fila organiza este problema de outra forma: a mensagem passa a ser um facto persistente no sistema, passível de rastreio, reprocessamento e recolha independente por vários destinatários. Esta não é uma escolha exclusivamente técnica. Dela depende se, perante uma reclamação de lote, uma paragem ou um incidente, será possível demonstrar o percurso das decisões do sistema e, assim, atribuir responsabilidade contratual, operacional ou interna. Onde a rastreabilidade é importante, vale a pena medir não só o atraso da resposta, mas também o número de mensagens que exigem reenvio, o tempo necessário para reconciliar o estado após uma falha e a possibilidade de reconstruir a sequência de eventos sem recorrer a uma reconstituição manual a partir de vários registos.

Este tema entra no domínio da avaliação de risco quando uma mensagem incorreta ou tardia pode alterar o comportamento da máquina, do processo ou de uma medida de proteção. Nesse caso, já não basta perguntar pela conveniência da integração; é necessário avaliar o efeito, a detetabilidade e a possibilidade de limitar as consequências, o que está em linha com a prática conhecida da ISO 12100. Se a comunicação disser respeito a funções relacionadas com a segurança, interbloqueios, condições de arranque ou confirmações do estado de energia, o limite da responsabilidade de projeto deixa de estar ao nível da aplicação e passa para o nível de todo o sistema da máquina. De forma semelhante, nos sistemas de atuação, incluindo os hidráulicos, um pressuposto errado quanto à entrega atempada da informação pode entrar em conflito com os princípios de conceção das medidas de proteção e dos estados seguros, o que conduz naturalmente a questões associadas à NP EN ISO 4413. Por outras palavras, filas e brokers não são “melhores por definição”, mas tornam-se a escolha adequada quando o projeto tem de resistir a uma falha de comunicação sem perder controlo, histórico e responsabilidade pelas ações executadas.

Como abordar o tema na prática

Na prática, a questão não é se a API REST é boa ou má, mas sim se se adequa às consequências do erro, do atraso e da ausência de resposta num determinado processo industrial. Se a comunicação servir sobretudo para leitura de dados, iniciação de tarefas administrativas ou integração com sistemas empresariais, uma interface de pedido–resposta pode ser a solução mais simples e mais económica. O problema começa quando o projeto pressupõe continuidade na troca de informação apesar da indisponibilidade temporária de uma das partes, necessidade de processamento ordenado de eventos ou obrigação de reconstituir quem, quando e com base em quê desencadeou uma determinada alteração de estado. Numa configuração deste tipo, a escolha de REST como mecanismo por defeito reduz muitas vezes o custo de entrada, mas aumenta o custo de gestão de falhas, de reconciliação do estado após uma interrupção e de esclarecimento de incidentes. É neste momento que filas, brokers e comunicação orientada a eventos deixam de ser um “acréscimo arquitetónico” e passam a ser uma ferramenta de redução do risco de projeto e da responsabilidade operacional.

Para a equipa e para o gestor, isto significa que a decisão arquitetónica tem de ser tomada com base em várias características mensuráveis do processo, e não nas preferências do fornecedor. O critério mais útil é simples: é preciso definir o que deve acontecer à mensagem quando o destinatário não responde no momento do envio. Se a resposta correta for “nada de crítico, a operação pode ser repetida ou rejeitada em segurança”, REST normalmente é suficiente. Se, pelo contrário, a mensagem tiver de ser preservada, entregue após a retoma da operação, processada uma única vez ou numa ordem que possa ser comprovada, então a arquitetura síncrona começa a afastar-se dos requisitos do processo. Vale a pena registar isso logo na fase de pressupostos como critérios de aceitação: tempo admissível de indisponibilidade do parceiro, forma de repetição, regras de deduplicação, possibilidade de rastrear a correlação entre eventos e modo de reconstituir o estado após uma falha. Sem estas definições, o projeto parece arrancar mais depressa, mas mais tarde regressa sob a forma de alterações de integração dispendiosas, disputas sobre o âmbito da responsabilidade e não conformidades operacionais difíceis de encerrar.

Um bom exemplo é uma linha ou célula em que o sistema de nível superior envia ordens, e os controladores e postos reportam a execução, rejeições, bloqueios ou mudanças entre modos de funcionamento. Se cada evento for imediatamente “consultado” via REST, uma perda momentânea de ligação faz surgir muito rapidamente um desfasamento entre o estado real e o estado visível na aplicação. Do ponto de vista da produção, isso acaba em reconciliação manual; do ponto de vista da qualidade, numa lacuna no histórico do lote; e, do ponto de vista da manutenção, na incerteza sobre se determinada instrução foi executada ou apenas enviada. Um broker com registo persistente de mensagens não resolve tudo, mas organiza as responsabilidades: o emissor transmitiu o evento, o sistema intermédio guardou-o, o destinatário confirmou-o ou não. Esta é uma diferença essencial na análise das causas de uma paragem e na verificação de se o erro resultou da lógica do processo, de uma falha de rede ou de uma sequência incorreta de ações do operador. É precisamente por isso que a decisão sobre o modelo de comunicação influencia não só o custo de implementação, mas também o tempo de arranque, de assistência e de auditoria.

Esta questão entra no domínio da avaliação prática do risco segundo a metodologia adotada quando a mensagem deixa de ser apenas informação e passa a ser uma condição para o funcionamento da máquina, do processo ou da medida de proteção. Se a possibilidade de arranque, de retoma do trabalho após uma paragem, de desbloqueio de uma sequência ou de confirmação do estado seguro da energia depender da transmissão correta do estado, então a decisão de integração passa a fazer parte de uma decisão de projeto com maior peso. Nesse caso, é necessário avaliar não só a disponibilidade da comunicação, mas também as consequências da sua perda, atraso, duplicação e interpretação incorreta; é aqui que surge naturalmente a metodologia conhecida da ISO 12100. Por outro lado, quando a comunicação interfere com as condições de prevenção do arranque inesperado, a camada de informação não pode ser tratada como substituto das soluções previstas para o corte de energia e para o estado seguro. Este é o limite em que o tema já toca a análise da proteção contra o arranque inesperado e, de forma mais ampla, o projeto do sistema da máquina para além da mera funcionalidade. Por outras palavras, o REST é adequado à indústria quando as suas limitações são conscientemente aceites pelo processo; quando não o são, os mecanismos de enfileiramento e de comunicação orientada a eventos tornam-se mais adequados, porque respondem melhor às exigências de continuidade, rastreabilidade e controlo dos efeitos das falhas.

O que ter em atenção na implementação

O erro mais frequente na implementação consiste em tratar a escolha entre REST API e comunicação orientada a eventos como uma decisão puramente técnica, quando, na indústria, se trata de uma decisão com consequências operacionais e organizacionais. O REST não deixa de funcionar só porque entra numa unidade de produção, mas revela muito rapidamente as suas limitações onde o sistema tem de absorver interrupções de ligação, carga irregular, indisponibilidades temporárias dos serviços e a necessidade de reconstruir posteriormente a sequência dos eventos. Se a arquitetura partir do princípio de que cada resposta tem de chegar de imediato e à primeira tentativa, o projeto torna-se frágil. A consequência é normalmente previsível: aumenta o custo da integração, multiplicam-se os mecanismos de contorno e a responsabilidade por um estado incorreto do processo dilui-se entre os fornecedores dos sistemas. Por sua vez, as filas e os brokers não resolvem o problema automaticamente; introduzem os seus próprios riscos, como processamento atrasado, duplicação de mensagens, necessidade de ordenar sequências e monitorização mais complexa. Por isso, a questão não é saber se o REST é sempre adequado à indústria, mas sim se um determinado processo tolera as características desta forma de comunicação sem transferir o risco para a produção, a manutenção e a conformidade.

Na fase de projeto, vale a pena adotar um critério simples de avaliação: o que acontece exatamente ao processo se a mensagem não chegar, chegar duas vezes ou chegar tarde demais. Se a consequência for apenas uma atualização tardia dos dados no sistema de reporte, o REST pode ser suficiente. Mas, se a ausência de resposta bloquear a sequência, obrigar a intervenção manual, levar à perda do histórico de execução das operações ou dificultar a determinação de quem tomou a decisão e com base em quê, então a arquitetura síncrona começa a gerar custos logo na fase de arranque. Nessa situação, a comunicação baseada em fila ou broker normalmente organiza melhor as responsabilidades: o emissor confirma o envio, o destinatário processa ao seu próprio ritmo e a equipa passa a ter a possibilidade de observar atrasos acumulados, reenvios e erros. Para o gestor de projeto, isto significa a necessidade de medir não só a disponibilidade do serviço, mas também indicadores como o tempo de permanência da mensagem em fila, a percentagem de reenvios, o número de mensagens por reconciliar e o tempo necessário para reconstruir o histórico de eventos após um incidente.

Na prática, o problema torna-se particularmente visível quando uma única integração começa a desempenhar várias funções ao mesmo tempo. Por exemplo: o sistema de nível superior envia uma ordem para um posto, recebe a confirmação da execução e, ao mesmo tempo, regista um estado que condiciona o arranque seguinte da linha. Enquanto estivermos a falar de troca de dados de negócio, um atraso de alguns segundos pode ser aceitável. No entanto, se o mesmo canal de comunicação começar a influenciar uma decisão de execução no processo, deixa de ser um complemento informático neutro. Nesse momento, uma escolha errada do mecanismo traduz-se não só no custo das paragens, mas também na responsabilidade por garantir que o sistema reage de forma previsível à falta de ligação, ao reinício do serviço ou à duplicação de uma mensagem. É aqui que o tema passa naturalmente para a área do projeto do sistema da máquina para além da mera funcionalidade: é preciso decidir quais os efeitos de falha que podem ser tolerados e quais exigem separação da camada de integração.

Esta fronteira torna-se ainda mais importante quando a comunicação começa a abranger condições relacionadas com a segurança funcional ou com a avaliação de risco. Se o cumprimento de uma condição de estado seguro, a autorização para retomar o funcionamento, a confirmação da ausência de energia perigosa ou qualquer outra função com relevância de proteção depender da correta troca de dados, as boas práticas de integração, por si só, não são suficientes. Nessa situação, é necessário definir com clareza se o elemento em análise continua a ser apenas uma camada informativa ou se já passa a integrar o âmbito do projeto de elementos dos sistemas de comando responsáveis por funções de segurança. É aqui que surgem as questões adequadas no contexto da NP EN ISO 13849-1 e da avaliação prática do risco segundo a abordagem conhecida da ISO 12100, mas apenas depois de definidas a função e as consequências da falha. Para a equipa, isto significa a obrigação de separar aquilo que pode ser tratado por fila, broker ou REST daquilo que não pode assentar exclusivamente em comunicação de uso geral. Se esta fronteira não for definida logo no início, o custo regressa mais tarde sob a forma de alterações ao projeto, litígios na receção e uma responsabilidade decisória difícil de sustentar.