Reestruturação do Servidor Backend para Interoperabilidade, Escalabilidade e Segurança através de APIs Bem Projetadas

doi:10.22167/2675-6528-202601350

19 de outubro de 2026

Reestruturação do Servidor Backend para Interoperabilidade, Escalabilidade e Segurança através de APIs Bem Projetadas

Reestruturação do Servidor Backend para Interoperabilidade, Escalabilidade e Segurança Através de Apis Bem Projetadas

Rariman Lara Silva da Rocha; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601350

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

O presente estudo propôs e implementou uma arquitetura backend orientada a APIs para sistemas de telemetria de equipamentos, com o objetivo de aprimorar o desempenho, a escalabilidade e a organização dos dados. Inicialmente, realizou-se uma análise das limitações de abordagens baseadas exclusivamente em bancos analíticos para aplicações em tempo real, que evidenciaram problemas de latência e acoplamento com o front-end. A partir desse diagnóstico, desenvolveu-se uma arquitetura híbrida, que separou dados analíticos e transacionais, e introduziu-se um processo de materialização de dados para consolidar informações da telemetria em um modelo otimizado para consulta. Paralelamente, construiu-se uma API REST no padrão Backend para Frontend (BFF), contemplando a definição de rotas, autenticação (OAuth2 e JWT), versionamento e documentação automatizada (Swagger/OpenAPI). Elaboraram-se regras de negócio para gestão de usuários, dispositivos e fluxos operacionais, e implementaram-se testes unitários abrangentes para validação de autenticação, idempotência de métodos HTTP e paginação. Os resultados demonstraram uma redução significativa no tempo de resposta das consultas, um aumento na confiabilidade das operações e a conformidade da API com as boas práticas de design e segurança. A abordagem proporcionou uma base estruturada para tomada de decisão e evolução do sistema, otimizando o consumo de informações pelos clientes e a utilização eficiente dos recursos computacionais, contribuindo para a sustentabilidade e a confiança do ecossistema digital.

Palavras-chave: Autenticação; Confiabilidade; Desempenho; Materialização de dados; Telemetria.

1. Introdução

O cenário tecnológico contemporâneo é marcado pela proliferação de sistemas distribuídos e pela expansão da Internet das Coisas (IoT), impulsionando a geração e o consumo massivo de dados. Nesse contexto, a telemetria de equipamentos assume papel fundamental, permitindo o monitoramento remoto e a coleta contínua de informações operacionais críticas. Milhares de módulos em campo, em diversos setores industriais, geram um volume significativo de dados, o que impõe desafios consideráveis em termos de escalabilidade, processamento e armazenamento (Newman, 2021). Para viabilizar a comunicação e a integração eficiente entre dispositivos e aplicações, as Interfaces de Programação de Aplicações (APIs) emergiram como elementos arquitetônicos indispensáveis. A arquitetura Representational State Transfer (REST), proposta por Fielding (2000), consolidou-se como paradigma dominante para o design de APIs web, promovendo padronização, simplicidade e capacidade de expansão. A literatura e a prática de mercado reiteram a importância das APIs como alicerce para ecossistemas digitais abertos, facilitando a interação entre aplicações (Newman, 2015; Fowler, 2019). A demanda por sistemas de telemetria robustos e responsivos exige, portanto, uma infraestrutura de backend que gerencie grandes volumes de dados de forma ágil e segura.

Apesar da ubiquidade das APIs, a concepção de interfaces bem estruturadas e seguras permanece um desafio complexo. Uma API, conforme definido pelo Institute of Electrical and Electronic Engineers (IEEE, 2021), é uma interface de software que estabelece um conjunto de funções e protocolos para a comunicação entre componentes de um sistema, promovendo interoperabilidade e modularização. O estilo arquitetural REST, por sua vez, baseia-se na manipulação de recursos identificados por URLs e no uso de operações padronizadas, como os métodos HTTP, enfatizando a ausência de estado e a separação entre cliente e servidor (Fielding, 2000). Tal abordagem contrasta com modelos como Chamadas de Procedimento Remoto (RPC) (Birrel e Nelson, 1984) e SOAP (World Wide Web Consortium, 2007). Para garantir a sustentabilidade e a usabilidade, Zimmermann et al. (2017) ressaltam a necessidade de práticas de governança, versionamento, autenticação robusta (OAuth2 e JWT) e documentação automatizada (Swagger/OpenAPI). Madden (2020) complementa, destacando que a segurança deve ser intrínseca ao design da API, incluindo validação rigorosa de dados e monitoramento contínuo.

A escolha da arquitetura de backend é crucial para o desempenho e a escalabilidade de sistemas de telemetria. Arquiteturas monolíticas, onde todas as funcionalidades são implementadas como uma única unidade, podem apresentar limitações em ambientes de alta demanda (Newman, 2020). Em contrapartida, arquiteturas baseadas em microserviços, que dividem o sistema em serviços autônomos que se comunicam via APIs, oferecem maior flexibilidade e escalabilidade (Newman, 2021). No contexto de telemetria, a persistência de dados frequentemente envolve bancos de dados do tipo Online Analytical Processing (OLAP), otimizados para grandes volumes e consultas analíticas complexas. Contudo, a utilização exclusiva de bancos OLAP para atender a aplicações em tempo real, que demandam respostas transacionais rápidas, pode resultar em problemas de latência e acoplamento excessivo com as camadas de apresentação, impactando a experiência do usuário. Para mitigar esses desafios, a materialização de dados surge como estratégia eficaz, consolidando informações da telemetria em um modelo otimizado para consulta, separando cargas analíticas das operacionais. Adicionalmente, o padrão Backend for Frontend (BFF) permite que a API seja adaptada às necessidades específicas de clientes, otimizando o consumo de informações e a utilização dos recursos.

A análise de arquiteturas de backend para sistemas de telemetria frequentemente revela gargalos de latência em consultas em tempo real e acoplamento excessivo com o front-end, devido ao uso exclusivo de bancos de dados analíticos para demandas operacionais. Tais limitações comprometem a performance, a escalabilidade e a organização dos dados, além de introduzir riscos de segurança pela ausência de boas práticas de design de APIs. O presente estudo justifica-se pela necessidade de desenvolver uma solução que supere essas deficiências, proporcionando um ambiente mais eficiente e confiável. Desta forma, o objetivo principal deste trabalho é propor e implementar uma arquitetura backend orientada a APIs para sistemas de telemetria de equipamentos, visando aprimorar o desempenho, a escalabilidade, a organização dos dados e a segurança das operações.

2. Material e Métodos

A pesquisa adotou uma metodologia aplicada, com abordagem qualitativa e descritiva, focada na análise e implementação de boas práticas de design e governança de Interfaces de Programação de Aplicações (APIs). Este estudo foi concebido como um caso prático, visando a reestruturação de um servidor backend para sistemas de telemetria de equipamentos. O objetivo central consistiu em investigar e aplicar diretrizes para modernizar a integração entre dispositivos em campo e sistemas web, buscando aprimorar desempenho, escalabilidade e segurança. A natureza aplicada da pesquisa permitiu a validação prática das soluções propostas em um ambiente operacional real, contribuindo para a resolução de um problema tecnológico específico.

O estudo foi conduzido em uma empresa de grande porte, fabricante de equipamentos médicos, situada no estado do Rio Grande do Sul, Brasil. A pesquisa foi desenvolvida especificamente na área de Engenharia de Projetos e Pesquisa e Desenvolvimento (P&D), departamento responsável pelo ciclo completo de desenvolvimento de produtos, incluindo aspectos mecânicos, de hardware e software. O período de realização do trabalho correspondeu ao ano de 2026, conforme a data de apresentação do Trabalho de Conclusão de Curso. A unidade de análise consistiu na arquitetura de backend existente e na proposta de reestruturação para sistemas de telemetria de equipamentos, visando aprimorar sua interoperabilidade, escalabilidade e segurança.

Considerando a natureza do estudo de caso, não houve uma população ou amostra definida no sentido estatístico tradicional. A pesquisa concentrou-se na arquitetura de backend de um sistema de telemetria existente na empresa, que gerenciava dados de milhares de módulos de equipamentos em campo. A unidade de análise foi o próprio sistema de backend, com foco em suas limitações de desempenho e acoplamento com o front-end. Os critérios de seleção para o escopo do estudo foram as deficiências identificadas na arquitetura legada, que justificaram a necessidade de uma reestruturação orientada a APIs para otimizar a performance e a segurança.

A coleta de dados iniciou-se com uma pesquisa bibliográfica abrangente, realizada nas bases de dados Google Acadêmico e ACM Digital Library. Foram utilizadas palavras-chave como “API design”, “API architecture”, “RESTful APIs”, “microservices architecture”, “API governance”, “API versioning” e “API security” para identificar publicações relevantes. A seleção dos artigos para leitura aprofundada baseou-se na relevância e aderência ao tema de arquitetura e projeto de APIs. Adicionalmente, consultaram-se livros e dissertações de referência na área, incluindo a dissertação de Fielding (2000) sobre arquitetura REST e o livro de Richardson et al. (2007) acerca da implementação de serviços RESTful, que fundamentaram os conceitos e diretrizes adotados.

Após a revisão bibliográfica, procedeu-se ao diagnóstico técnico do ambiente de backend existente na empresa. Este diagnóstico visou identificar a estrutura atual do servidor, os padrões de integração empregados, as limitações de interoperabilidade e os pontos críticos de falha relacionados à escalabilidade e segurança das comunicações entre dispositivos e sistemas. A partir dessa análise, elaborou-se um diagrama C4, que representou a arquitetura proposta para a reestruturação do backend. Este diagrama detalhou os componentes, contêineres e fluxos de integração atualizados, servindo como ferramenta comparativa para evidenciar as melhorias esperadas em termos de interoperabilidade, escalabilidade e segurança da solução.

Com base nas boas práticas identificadas na literatura e nas demandas do ambiente estudado, elaborou-se um novo modelo de arquitetura backend orientado a APIs. O desenvolvimento concentrou-se na camada de serviços, implementando uma API REST no padrão Backend for Frontend (BFF). Esta etapa envolveu a concepção de endpoints e regras de negócio específicas para atender às diferentes aplicações de frontend. Foram definidos padrões de autenticação, controle de versão e a criação de documentação automatizada, visando facilitar a integração e a manutenção do sistema, garantindo que a API fosse robusta e adaptável às necessidades dos clientes.

A estruturação dos endpoints da API seguiu uma convenção de rotas padronizada, composta por um prefixo técnico (/api), a identificação do canal consumidor (como /web ou /mobile), um versionamento explícito (/v1) e a segmentação por domínio funcional (por exemplo, /auth e /users). Essa abordagem foi adotada para reduzir o acoplamento entre os clientes, otimizar a organização da documentação da API e permitir a evolução independente dos contratos expostos. A Tabela 1 apresenta exemplos detalhados de endpoints da API, ilustrando a aplicação dessa convenção por canal consumidor, versão e domínio funcional, facilitando a compreensão da estrutura implementada.

Tabela 1. Exemplos de endpoints da API

Endpoint	Canal	Versão	Domínio	Finalidade
/api/web/v1/auth/login	Web	v1	Autenticação	Realizar autenticação na web
/api/web/v1/users/me	Web	v1	Usuários	Retornar dados do usuário autenticado na web
/api/web/v1/devices/{id}/details/	Web	v1	Equipamentos	Retornar detalhes do equipamento #id na web
/api/web/v1/devices/locations/?page=1&page_size=5000	Web	v1	Equipamentos	Retornar última localização dos equipamentos usando paginação na web
/api/mobile/v1/auth/login	Mobile	v1	Autenticação	Realizar autenticação no mobile
/api/mobile/v1/users/me	Mobile	v1	Usuários	Retornar dados do usuário autenticado no mobile
/api/mobile/v1/devices/{id}/details/	Mobile	v1	Equipamentos	Retornar detalhes do equipamento #id no mobile
/api/mobile/v1/devices/locations/?page=1&page_size=5000	Mobile	v1	Equipamentos	Retornar última localização dos equipamentos usando paginação no mobile

Fonte: Dados originais da pesquisa

Após a implementação da arquitetura, realizou-se uma etapa rigorosa de testes e validações, abrangendo aspectos funcionais, de desempenho e de segurança da API. Os testes funcionais foram projetados para verificar a aderência dos endpoints à documentação Swagger/OpenAPI, incluindo campos obrigatórios, tipos de dados, códigos HTTP e mensagens de erro padronizadas. Também se avaliou a idempotência dos métodos GET, PUT e DELETE, a consistência da paginação e filtros, e a robustez dos mecanismos de autenticação e autorização baseados em JSON Web Tokens (JWT). A validação do sistema foi guiada por critérios de aceitação bem definidos, garantindo a confiabilidade e a conformidade com os requisitos estabelecidos.

O planejamento dos casos de teste envolveu a identificação e organização de cenários de avaliação, detalhando dados de entrada, condições de execução e resultados esperados para cada um. Foram contemplados tanto cenários positivos, que verificavam o comportamento correto do sistema, quanto cenários negativos, focados na validação do tratamento de erros e exceções. O escopo dos testes foi cuidadosamente delimitado para priorizar funcionalidades e componentes críticos, com especial atenção às rotas de autenticação, controle de acesso e manipulação de dados. Essa abordagem garantiu que os pontos de maior impacto na segurança e no funcionamento geral da aplicação fossem exaustivamente avaliados.

Os testes foram implementados de forma automatizada utilizando a ferramenta `pytest`, permitindo a execução repetitiva, padronizada e consistente dos cenários definidos. Essa automação facilitou a detecção precoce de falhas e a validação contínua das funcionalidades ao longo do desenvolvimento, contribuindo para a robustez e qualidade do sistema. Os casos de teste, detalhados nos apêndices do trabalho, abrangeram autenticação de usuários, fluxo de tokens, idempotência dos métodos HTTP PUT e DELETE, e paginação de resultados. A análise dos dados coletados durante os testes foi realizada por meio da comparação dos resultados obtidos antes e depois da reestruturação, utilizando tabelas e gráficos para mensurar o impacto na eficiência operacional e na sustentabilidade da arquitetura de APIs.

A análise dos dados de teste focou na verificação da conformidade da API com os requisitos funcionais e de segurança. Para a autenticação, avaliou-se a correta validação de usuários, o tratamento de requisições inválidas e a consistência das respostas. No fluxo de tokens, verificou-se a geração, validação, renovação e expiração dos tokens de acesso, além do tratamento de usos indevidos. A idempotência dos métodos PUT e DELETE foi analisada para garantir a consistência do estado dos recursos após múltiplas execuções. Por fim, a paginação foi testada quanto à navegação, controle de itens por requisição e tratamento de valores inválidos, assegurando a previsibilidade e coerência dos resultados.

Este estudo, de natureza técnica e focado na reestruturação de uma arquitetura de software, não envolveu a participação de seres humanos ou a coleta de dados sensíveis, portanto, não demandou a aplicação de procedimentos éticos formais. Quanto às limitações metodológicas, o trabalho concentrou-se em um estudo de caso específico, o que pode restringir a generalização direta dos resultados para outros contextos organizacionais ou sistemas de telemetria com características substancialmente diferentes. Contudo, a abordagem detalhada e a validação prática da solução proposta oferecem um modelo replicável e adaptável para cenários similares, contribuindo com um arcabouço de boas práticas.

3. Resultados e Discussão

A presente seção de Resultados e Discussões detalha os achados da pesquisa, iniciando com a contextualização dos princípios e métodos para o projeto de APIs, seguida pela análise da arquitetura legada, a proposição da nova arquitetura e a apresentação dos resultados dos testes unitários. O objetivo central foi investigar e aplicar boas práticas de design e governança de APIs para reestruturar um servidor backend de telemetria, visando aprimorar desempenho, escalabilidade e segurança. A metodologia aplicada, de natureza qualitativa e descritiva, permitiu a validação prática das soluções em um ambiente operacional real, fornecendo um arcabouço de boas práticas para cenários tecnológicos similares.

A compreensão das Interfaces de Programação de Aplicações (APIs) é fundamental para a integração de sistemas modernos. Segundo o Institute of Electrical and Electronic Engineers (IEEE, 2021), uma API é uma interface de software que estabelece um conjunto de funções, métodos e protocolos, permitindo a comunicação e a interoperabilidade entre diferentes componentes de um sistema. Essa definição ressalta o papel crucial das APIs na modularização e na capacidade de sistemas heterogêneos se comunicarem de forma eficiente. No contexto atual de ecossistemas digitais, as APIs não são apenas ferramentas técnicas, mas representam a forma como as organizações expõem suas funcionalidades e modelos de negócio, tornando-se interfaces estratégicas para desenvolvedores e para a criação de novas integrações (Jin et al., 2018). A qualidade do design de uma API, portanto, reflete diretamente na usabilidade, segurança e sustentabilidade do sistema que a expõe.

Diferentes paradigmas arquiteturais de APIs coexistem, cada um com suas particularidades em termos de interação, acoplamento e complexidade. O estilo arquitetural Representational State Transfer (REST), proposto por Fielding (2000), consolidou-se como um dos modelos mais influentes para o design de APIs web modernas. A principal característica do REST é a ausência de estado (statelessness), onde cada requisição do cliente ao servidor contém todas as informações necessárias para ser compreendida, sem que o servidor precise armazenar o contexto da sessão do cliente entre as requisições. Essa abordagem promove a simplicidade, a escalabilidade e a separação de preocupações entre cliente e servidor, facilitando a evolução independente de ambos os lados da comunicação. A adesão aos princípios RESTful, como o uso de recursos identificados por URLs e operações padronizadas (métodos HTTP), é um indicador de maturidade de uma API, conforme o Modelo de Maturidade de Richardson et al. (2007), que classifica as APIs em níveis de aderência a esses princípios, desde chamadas de procedimento remoto (Nível 0) até a incorporação de hipermedia como motor do estado da aplicação (HATEOAS, Nível 3).

Em contraste com o REST, outros paradigmas também são amplamente utilizados. As Chamadas de Procedimento Remoto (RPC), por exemplo, visam permitir a execução de funções em um servidor remoto como se fossem chamadas locais (Birrel e Nelson, 1984). Embora simplifiquem a invocação de métodos, as APIs RPC tendem a gerar maior acoplamento entre cliente e servidor, pois a comunicação é orientada a ações específicas, e não a recursos. Outro protocolo notável é o Simple Object Access Protocol (SOAP), um padrão baseado em XML que define um formato estruturado para mensagens e regras rigorosas de comunicação (W3C, 2007). O SOAP é frequentemente empregado em arquiteturas orientadas a serviços que demandam formalização de contratos, segurança e confiabilidade elevadas, mas sua complexidade pode ser um obstáculo em cenários que exigem maior agilidade. Por fim, o GraphQL, uma especificação de API orientada a consultas, oferece aos clientes a flexibilidade de definir exatamente quais dados desejam obter, reduzindo o volume de dados transferidos e otimizando a eficiência da comunicação entre frontend e backend, operando geralmente por meio de um único endpoint HTTP (Porcello e Banks, 2018). A escolha do paradigma de API depende, portanto, dos requisitos específicos do projeto, considerando fatores como flexibilidade, acoplamento, desempenho e facilidade de uso.

A perspectiva arquitetural também é crucial na classificação e no projeto de APIs, influenciando diretamente a escalabilidade, acoplamento, desempenho e manutenibilidade das aplicações. A arquitetura monolítica, conforme descrito por Newman (2020), consiste em uma única unidade de implantação onde todas as funcionalidades são implementadas e disponibilizadas em conjunto. Embora possa ser mais simples de desenvolver e implantar inicialmente, um monólito de processo único, onde todo o código é executado como um único processo, pode enfrentar desafios de escalabilidade e robustez, mesmo com múltiplas instâncias.

Fonte: Newman (2020)

Figura 1. Monolito de processo único: todo código é executado em um único processo

A Figura 1 ilustra a estrutura básica de um monólito de processo único, onde o aplicativo e o banco de dados estão fortemente acoplados. Uma variação, o monólito modular, organiza o sistema em módulos logicamente distintos, que podem ser desenvolvidos e mantidos de forma independente, mas ainda são integrados e implantados como uma única unidade (Newman, 2020).

Fonte: Newman (2020)

Figura 2. Monólito de processo único: o código dentro do processo é dividido em módulos

A Figura 2 demonstra essa separação lógica dentro de um monólito, o que pode melhorar a organização interna, mas não resolve completamente os desafios de implantação e escalabilidade inerentes a uma única unidade. Em contrapartida, a arquitetura de microserviços, conforme detalhado por Newman (2021), consiste em serviços que podem ser implantados de maneira independente, cada um estruturado em torno de domínios de negócio específicos e comunicando-se por meio de APIs. Essa abordagem evita o compartilhamento de bancos de dados, com cada serviço sendo responsável por seu próprio repositório de dados, promovendo maior autonomia e resiliência.

Fonte: Newman (2020)

Figura 3. Microserviços: serviços são executados de maneira independente

A Figura 3 representa a arquitetura de microserviços, destacando a independência dos serviços e seus respectivos bancos de dados, o que confere maior flexibilidade e escalabilidade ao sistema. A adoção de microserviços, embora traga complexidade adicional na gestão e orquestração, é frequentemente justificada pela necessidade de sistemas altamente escaláveis, resilientes e com ciclos de desenvolvimento independentes.

A caracterização da arquitetura do sistema em nuvem legado da organização revelou um cenário comum em sistemas de telemetria de equipamentos. Cada equipamento fabricado pela empresa possui um módulo embarcado que adquire e transmite dados operacionais, gerando um volume significativo de informações. O backend existente, no entanto, estava estruturado como um monólito, onde todas as funcionalidades eram implementadas e implantadas como uma única unidade. Essa abordagem, embora funcional para um estágio inicial, apresentava limitações significativas à medida que o volume de dados e a demanda por interatividade em tempo real cresciam. A exposição das funcionalidades aos frontends web e mobile era realizada por meio de uma API baseada em GraphQL, que, apesar de oferecer flexibilidade nas consultas, concentrava regras de negócio, acesso a dados e camadas de serviço em um único processo, impactando a escalabilidade e a manutenibilidade.

Fonte: Resultados originais da pesquisa

Figura 4. Principais componentes do sistema atual

Conforme ilustrado na Figura 4, o sistema legado apresentava um acoplamento direto entre a camada de serviços (Backend BFF / GraphQL) e o banco de dados OLAP (Online Analytical Processing). Este banco de dados, otimizado para suportar grandes volumes de dados e consultas analíticas complexas, mostrava-se ineficiente para cenários que exigiam respostas transacionais rápidas e baixa latência. A utilização de um banco de dados OLAP para atender a demandas de tempo real resultava em lentidão na renderização de informações na interface do usuário, comprometendo a experiência geral. Essa limitação é um problema recorrente em arquiteturas monolíticas que tentam conciliar cargas de trabalho analíticas e transacionais no mesmo repositório de dados, evidenciando a necessidade de desacoplamento e otimização para diferentes perfis de acesso. A falta de separação clara entre as responsabilidades de ingestão, processamento e consumo de dados contribuía para um sistema menos resiliente e mais difícil de escalar horizontalmente, uma vez que qualquer gargalo em uma parte do monólito afetava o desempenho de todo o sistema.

A proposta de nova arquitetura em nuvem buscou resolver as limitações identificadas no sistema legado, adotando uma abordagem híbrida que desacopla as cargas analíticas das demandas de leitura em tempo quase real. Esta reestruturação foi concebida para garantir escalabilidade, melhorar o desempenho e otimizar a organização dos dados.

Fonte: Resultados originais da pesquisa

Figura 5. Diagrama C4 em visão de container

A Figura 5, que apresenta o diagrama C4 em nível de container da nova arquitetura, detalha a separação de responsabilidades. Os equipamentos em campo continuam enviando dados de telemetria para um Serviço de Ingestão de Dados via WebSocket, que os persiste no Banco de Dados Analítico (OLAP). Esta etapa mantém a compatibilidade com o sistema legado de coleta de dados. A inovação reside na introdução de um Serviço de Consolidação de Dados, que processa e materializa os dados brutos do OLAP, armazenando-os em um Banco de Dados Transacional (OLTP). Este banco de dados é otimizado para consultas de baixa latência, atendendo às necessidades das aplicações de frontend. Os usuários interagem com o sistema por meio de Aplicações Web e Mobile, que consomem uma API REST fornecida pelo Backend para Frontend (BFF). Essa arquitetura promove um desacoplamento fundamental entre o processamento analítico e o consumo operacional, resultando em melhor desempenho para uso interativo. A separação entre OLAP e OLTP, com um processo de materialização de dados, é uma prática alinhada com os princípios de arquiteturas de dados modernas que buscam otimizar o acesso e o processamento para diferentes cargas de trabalho, conforme discutido por Fowler (2002) em padrões de arquitetura empresarial.

Fonte: Resultados originais da pesquisa

Figura 6. Principais componentes da solução proposta

A Figura 6 complementa a visão do diagrama C4, representando os principais componentes da solução proposta em três camadas: apresentação, serviços e dados. Na camada de apresentação, os clientes web e mobile consomem dados via requisições à API, exibindo dashboards e relatórios operacionais. A camada de serviços é composta pelo Serviço de Ingestão de Telemetria (recebendo dados via WebSocket), o Serviço de Materialização (consolidando dados do OLAP para o OLTP) e a API REST Backend/BFF (abstraindo a complexidade dos dados e fornecendo respostas otimizadas). A camada de dados utiliza o banco OLAP para dados brutos de telemetria e o banco OLTP para dados consolidados e de baixa latência, essenciais para a gestão e autenticação de usuários. Este fluxo de dados, dividido em processos de escrita (coleta, persistência no OLAP, materialização no OLTP) e leitura (frontend acessando a API para dados consolidados do OLTP), garante maior eficiência e melhor experiência do usuário. A abordagem de Backend for Frontend (BFF) é particularmente relevante aqui, pois permite que a API seja adaptada às necessidades específicas de cada tipo de cliente (web ou mobile), reduzindo o acoplamento e otimizando o consumo de informações, uma prática recomendada por Newman (2020) para arquiteturas distribuídas. A compatibilidade com o sistema legado, mantendo o histórico completo dos dados coletados, é um benefício adicional que assegura a integridade e a continuidade operacional.

A elaboração da API REST foi um componente central da pesquisa, com foco na concepção e desenvolvimento da camada de serviços no padrão Backend for Frontend (BFF). Esta camada atua como um intermediário estratégico entre as aplicações clientes e os repositórios de dados, permitindo que as respostas sejam adequadas às necessidades específicas de cada tipo de frontend e às regras de negócio associadas. A adoção do padrão BFF é uma prática reconhecida por sua capacidade de otimizar a experiência do desenvolvedor de frontend, fornecendo uma API que é precisamente moldada para o consumo de uma aplicação específica, em vez de uma API genérica que tenta atender a múltiplos clientes com diferentes requisitos. Isso minimiza a sobrecarga de dados e a complexidade no lado do cliente, resultando em aplicações mais eficientes e com melhor desempenho.

A estruturação dos endpoints da API seguiu uma convenção de rotas padronizada, composta por um prefixo técnico (`/api`), a identificação do canal consumidor (`/web` ou `/mobile`), um versionamento explícito (`/v1`) e a segmentação por domínio funcional (`/auth` e `/users`).

Fonte: Resultados originais da pesquisa

Figura 7. Decomposição do endpoint

A Figura 7 ilustra a decomposição do endpoint, evidenciando como cada segmento da rota contribui para a organização e clareza da API. Essa estratégia de design é crucial para reduzir o acoplamento entre os clientes e a API, pois permite que diferentes versões e canais de consumo coexistam e evoluam independentemente. Além disso, melhora significativamente a organização da documentação da API, tornando-a mais fácil de ser compreendida e utilizada por desenvolvedores. A padronização dos endpoints, como demonstrado na Tabela 1, que apresenta exemplos detalhados de endpoints da API por canal consumidor, versão e domínio funcional, é uma prática fundamental para a governança de APIs. Zimmermann et al. (2017) enfatizam que a governança de APIs, incluindo versionamento e documentação automatizada (como Swagger/OpenAPI), é essencial para a sustentabilidade e usabilidade a longo prazo. A clareza e a previsibilidade das rotas facilitam a integração de novos serviços e a manutenção dos existentes, garantindo que a API seja robusta e adaptável às necessidades dos clientes e à evolução do sistema. A Tabela 1, conforme apresentado na seção de Materiais e Métodos, exemplifica essa convenção de rotas, mostrando como diferentes canais (web, mobile) e domínios funcionais (autenticação, usuários, equipamentos) são organizados sob um versionamento explícito, o que é vital para gerenciar a evolução da API sem quebrar as integrações existentes.

Os testes unitários das rotas de autenticação foram cruciais para validar a segurança e a funcionalidade da API. A execução dos casos de teste especificados no Apêndice A, utilizando a ferramenta `pytest`, permitiu uma análise abrangente de cenários funcionais e de segurança.

Fonte: Resultados originais da pesquisa

Figura 8. Resultado da execução dos testes automatizados de autenticação

A Figura 8 apresenta os resultados dos testes unitários de autenticação, mostrando que todos os 10 testes foram aprovados, com tempos de execução eficientes. Esses resultados demonstram a robustez da API em lidar com diversas situações de autenticação.

Primeiramente, a API realiza corretamente a autenticação de usuários válidos, retornando os dados esperados (CT01). Isso valida a funcionalidade básica de login, assegurando que usuários com credenciais corretas possam acessar o sistema. A implicação prática é a garantia de que o ponto de entrada principal do sistema é funcional e confiável, permitindo que os usuários legítimos interajam com a aplicação sem impedimentos. Este achado é fundamental para a usabilidade e a adoção do sistema, pois um processo de autenticação fluido é a base para qualquer interação segura.

Em segundo lugar, a API rejeita adequadamente requisições inválidas ou incompletas, com respostas de erro controladas e sem emissão de tokens (CT02 e CT03). Este comportamento é vital para a segurança, pois impede tentativas de acesso não autorizado e fornece feedback claro sobre falhas de autenticação. A prática de retornar mensagens de erro padronizadas e informativas, sem expor detalhes internos do sistema, é uma boa prática de segurança que contribui para a resiliência da API contra ataques de força bruta ou engenharia social, conforme recomendado por Madden (2020).

Terceiro, a API valida corretamente a obrigatoriedade e consistência dos dados de entrada, tratando requisições incompletas ou inválidas com respostas de erro apropriadas (CT04, CT05 e CT06). Essa validação rigorosa na camada de entrada é uma defesa primária contra injeção de dados maliciosos e garante a integridade das informações processadas. A conformidade com os tipos de dados e campos obrigatórios é um pilar do design de APIs robustas, prevenindo erros no processamento e garantindo a estabilidade do sistema.

Quarto, a API garante o controle de acesso adequado, impedindo a autenticação de usuários inativos (CT07). Este é um requisito de segurança crítico, pois impede que contas desativadas ou suspensas sejam utilizadas para acessar o sistema. A gestão de estados de usuário, como ativo/inativo, é uma funcionalidade essencial para a governança de usuários e para a manutenção da segurança do sistema ao longo do tempo, alinhando-se com as diretrizes de controle de acesso em sistemas distribuídos.

Quinto, a API apresenta conformidade com o contrato da API, especialmente no que se refere à restrição de métodos HTTP permitidos (CT08). Isso significa que a API responde com o código de status HTTP 405 (Method Not Allowed) para métodos não suportados em um determinado endpoint, garantindo que apenas as operações esperadas sejam aceitas. A aderência aos métodos HTTP (GET, POST, PUT, DELETE) e seus significados semânticos é um princípio fundamental do REST, conforme Fielding (2000), que promove a interoperabilidade e a previsibilidade do comportamento da API.

Sexto, a API mantém consistência na estrutura das respostas em cenários de sucesso, atendendo aos requisitos definidos (CT09). A padronização da estrutura das respostas facilita o consumo da API pelos clientes, reduzindo a complexidade de integração e o tempo de desenvolvimento. Uma estrutura de resposta consistente é um indicativo de um design de API maduro e bem documentado, contribuindo para a experiência do desenvolvedor.

Por fim, a API atende aos critérios de segurança, não expondo informações sensíveis no “payload” de resposta (CT10). Este é um aspecto crucial da segurança da informação, prevenindo a divulgação acidental de dados confidenciais que poderiam ser explorados por atacantes. A filtragem de informações sensíveis nas respostas da API é uma prática de segurança essencial que protege a privacidade dos usuários e a integridade do sistema, conforme as melhores práticas de segurança de APIs (Madden, 2020).

Os testes unitários relacionados ao fluxo de autenticação baseado em “tokens” foram igualmente bem-sucedidos, validando os mecanismos de geração, validação, renovação e expiração de tokens de acesso, bem como o tratamento de usos indevidos.

Fonte: Resultados originais da pesquisa

Figura 9. Resultado da execução dos testes automatizados de autenticação

A Figura 9 mostra que todos os 15 testes de fluxo de tokens foram aprovados, incluindo um teste de desempenho, demonstrando a robustez do sistema.

Em primeiro lugar, o sistema gera corretamente tokens de acesso e de renovação para usuários autenticados (CT11 e CT18). Isso é fundamental para a segurança e a experiência do usuário, pois os tokens são a base para o acesso a recursos protegidos e para manter a sessão ativa sem a necessidade de reautenticação constante. A correta geração de JSON Web Tokens (JWT) e tokens de refresh, conforme as especificações de OAuth2, é um pilar da segurança moderna de APIs, garantindo que as credenciais de acesso sejam efêmeras e gerenciáveis.

Em segundo lugar, a API permite o acesso a rotas protegidas apenas mediante a utilização de tokens válidos (CT12). Este controle de acesso baseado em tokens é essencial para proteger os recursos do sistema contra acessos não autorizados. A validação de cada token em cada requisição a um recurso protegido assegura que apenas usuários autenticados e autorizados possam interagir com as funcionalidades sensíveis da aplicação, reforçando a segurança da API.

Terceiro, a API rejeita adequadamente tokens ausentes, inválidos, malformados ou utilizados de forma incorreta (CT13, CT14, CT15 e CT21). Esse comportamento é crucial para prevenir ataques de injeção de tokens ou tentativas de acesso com credenciais falsificadas. A robustez na validação de tokens é uma linha de defesa crítica, garantindo que apenas tokens legítimos e bem formados sejam aceitos, conforme as diretrizes de segurança de APIs (Madden, 2020).

Quarto, a API garante a separação adequada entre *access token* e *refresh token*, impedindo seu uso indevido (CT16 e CT22). Essa separação é uma prática de segurança recomendada, onde o *access token* tem um tempo de vida curto e é usado para acessar recursos, enquanto o *refresh token* tem um tempo de vida mais longo e é usado apenas para obter novos *access tokens*. Isso minimiza o risco de comprometimento de credenciais de longa duração, pois mesmo que um *access token* seja interceptado, seu tempo de validade limitado reduz a janela de ataque.

Quinto, o sistema implementa corretamente o mecanismo de expiração de tokens, assegurando a invalidação após o tempo definido (CT23 e CT24). A expiração de tokens é um componente essencial da segurança, pois limita o tempo que um token comprometido pode ser usado. A validação da expiração do token, tanto para *access tokens* quanto para *refresh tokens*, é fundamental para a gestão de sessões seguras e para a mitigação de riscos de segurança.

Por fim, a API apresenta desempenho adequado nas operações de autenticação e renovação de tokens (CT17). A eficiência no processamento de requisições de autenticação e renovação de tokens é vital para a experiência do usuário e para a escalabilidade do sistema. Tempos de resposta rápidos nessas operações garantem que a autenticação não se torne um gargalo de desempenho, mesmo sob alta carga, contribuindo para a sustentabilidade da arquitetura.

Os testes unitários de idempotência dos métodos PUT e DELETE foram realizados para verificar a consistência do estado dos recursos após múltiplas execuções da mesma operação, bem como a ausência de efeitos colaterais indesejados.

Fonte: Resultados originais da pesquisa

Figura 10. Resultado da execução dos testes automatizados de idempotência

A Figura 10 mostra que todos os 6 testes de idempotência foram aprovados, com tempos de execução rápidos.

Em primeiro lugar, a API mantém a consistência do estado do recurso após múltiplas execuções de requisições PUT idênticas, caracterizando comportamento idempotente (CT25). A idempotência é um princípio fundamental do design RESTful, conforme Richardson et al. (2007), que garante que a execução repetida de uma operação PUT não altere o estado do recurso além da primeira execução. Isso é crucial para a confiabilidade de sistemas distribuídos, onde requisições podem ser retentadas devido a falhas de rede ou temporárias, sem causar inconsistências de dados.

Em segundo lugar, a API não gera duplicidade de dados quando a mesma operação PUT é executada repetidamente (CT26). Este achado reforça a idempotência do método PUT, assegurando que a atualização de um recurso não resulte na criação de registros duplicados, o que poderia levar a dados inconsistentes e problemas de integridade no banco de dados. A prevenção de duplicidade é um benefício direto da correta implementação da idempotência.

Terceiro, a API garante que requisições DELETE sucessivas mantêm o recurso em estado de ausência, sem reverter ou alterar o resultado esperado (CT27). Similarmente ao PUT, o método DELETE deve ser idempotente, ou seja, múltiplas requisições para remover o mesmo recurso devem resultar no mesmo estado final (recurso ausente), sem gerar erros ou efeitos colaterais. Isso é essencial para a robustez do sistema, permitindo que operações de exclusão sejam retentadas com segurança.

Quarto, a API trata adequadamente chamadas repetidas de DELETE, não ocasionando erros internos no servidor (CT28). A capacidade de lidar com requisições DELETE repetidas sem falhas internas demonstra a resiliência da API. Isso é particularmente importante em ambientes distribuídos, onde a comunicação pode ser instável e requisições podem ser enviadas múltiplas vezes, e a API deve ser capaz de processá-las sem comprometer sua estabilidade.

Quinto, a API utiliza corretamente o método PUT para atualização de recursos, sem efeitos colaterais indevidos (CT29). A correta semântica do PUT, que é a substituição completa de um recurso, é validada, garantindo que as atualizações sejam previsíveis e não introduzam efeitos não intencionais no sistema. Isso contribui para a clareza e a manutenibilidade da API.

Por fim, a API aplica corretamente o método DELETE para remoção de recursos, assegurando comportamento previsível e consistente (CT30). A validação do DELETE confirma que a remoção de recursos ocorre de forma esperada, sem deixar rastros ou estados inconsistentes. A previsibilidade do comportamento dos métodos HTTP é um pilar para a construção de APIs RESTful que são fáceis de entender e integrar.

Os testes unitários de paginação foram conduzidos para validar o mecanismo de paginação da rota de listagem de dispositivos, abrangendo cenários funcionais, validação de parâmetros e consistência da resposta da API.

Fonte: Resultados originais da pesquisa

Figura 11. Resultado da execução dos testes automatizados de paginação

A Figura 11 mostra que todos os 15 testes de paginação foram aprovados, com tempos de execução consistentes.

Em primeiro lugar, a API retorna corretamente a primeira página de resultados, respeitando os parâmetros informados (CT31). Isso valida a funcionalidade básica de paginação, garantindo que os usuários possam solicitar e receber a primeira parte de um conjunto de dados de forma previsível. A correta implementação da paginação é essencial para gerenciar grandes volumes de dados, melhorando o desempenho e a experiência do usuário ao evitar a transferência de todos os dados de uma só vez.

Em segundo lugar, a API permite a navegação entre páginas distintas sem repetição indevida de registros (CT32). A capacidade de navegar para páginas subsequentes sem encontrar registros duplicados é crucial para a integridade dos dados apresentados e para uma experiência de usuário fluida. Isso demonstra que o mecanismo de paginação está gerenciando corretamente os offsets e limites de dados entre as requisições.

Terceiro, a API respeita o limite de itens definido pelo parâmetro `page_size` (CT33). A imposição do `page_size` garante que a quantidade de dados retornados em cada requisição seja controlada, otimizando o uso da largura de banda e o tempo de processamento no cliente. Essa flexibilidade permite que os clientes ajustem a granularidade da paginação conforme suas necessidades.

Quarto, a API aplica corretamente a paginação padrão quando os parâmetros não são informados (CT34). A definição de um comportamento padrão para a paginação, quando os parâmetros `page` e `page_size` não são fornecidos, é uma boa prática de design de API que melhora a usabilidade e a robustão, garantindo que a API sempre retorne um conjunto de dados paginado, mesmo em requisições simplificadas.

Quinto, a API trata adequadamente requisições para páginas além do total disponível, retornando resposta controlada (CT35). Em vez de gerar um erro de servidor, a API deve retornar uma resposta indicando que a página solicitada está vazia ou que não existe, o que é um comportamento esperado e robusto. Isso evita falhas inesperadas e fornece feedback claro ao cliente.

Sexto, a API rejeita valores inválidos para o parâmetro `page`, como zero ou negativos (CT36 e CT37). A validação rigorosa dos parâmetros de entrada é fundamental para a segurança e a estabilidade da API, prevenindo que valores maliciosos ou incorretos causem comportamentos inesperados ou erros internos.

Sétimo, a API rejeita valores inválidos para o parâmetro `page_size`, como zero ou negativos (CT38 e CT39). Similarmente ao parâmetro `page`, a validação do `page_size` garante que apenas valores positivos e razoáveis sejam aceitos, evitando requisições que poderiam sobrecarregar o servidor ou retornar resultados indesejados.

Oitavo, a API limita corretamente o valor máximo de `page_size` ou trata valores excessivos de forma controlada (CT40). A imposição de um limite máximo para o `page_size` é uma medida de segurança e desempenho, prevenindo que um cliente solicite um número excessivamente grande de itens em uma única requisição, o que poderia levar a gargalos de desempenho ou ataques de negação de serviço.

Nono, a API valida o tipo dos parâmetros de paginação, rejeitando valores não numéricos (CT41 e CT42). A validação de tipos de dados é uma prática de segurança essencial, garantindo que apenas entradas numéricas sejam aceitas para os parâmetros `page` e `page_size`, protegendo a API contra injeção de código ou outros ataques baseados em tipos de dados incorretos.

Décimo, a API mantém a consistência da estrutura da resposta paginada, conforme o contrato da API (CT43). A padronização da estrutura da resposta, incluindo metadados como `count`, `next` e `results`, facilita o consumo da API pelos clientes e garante uma experiência de integração consistente.

Décimo primeiro, a API garante a ausência de sobreposição indevida de registros entre páginas consecutivas (CT44). A ausência de sobreposição é crucial para a integridade dos dados e para garantir que cada registro seja apresentado uma única vez durante a navegação paginada.

Por fim, a API aplica corretamente a paginação em conjunto com filtros, mantendo a coerência dos resultados retornados (CT45). A capacidade de combinar paginação com filtros é uma funcionalidade avançada que permite aos usuários refinar suas buscas em grandes conjuntos de dados de forma eficiente, demonstrando a flexibilidade e a robustez da API.

Em síntese, o diagnóstico da arquitetura legada evidenciou limitações significativas no uso exclusivo de OLAP para atendimento em tempo real, resultando em alta latência e acoplamento com o frontend. A adoção de uma arquitetura híbrida, com a separação entre OLAP e OLTP e a implementação de um processo de materialização de dados, demonstrou ser uma solução eficaz. Essa abordagem trouxe ganhos substanciais de desempenho e organização, permitindo consultas mais rápidas e consistentes, o que se alinha com as melhores práticas de design de sistemas distribuídos (Fowler, 2002). A implementação de uma API no padrão Backend for Frontend (BFF), aliada à definição de regras de negócio e a uma bateria rigorosa de testes de validação, aumentou a confiabilidade e a adequação das respostas aos clientes. Os resultados dos testes unitários de autenticação, fluxo de tokens, idempotência e paginação confirmaram a conformidade da API com os requisitos funcionais e de segurança, bem como sua aderência às boas práticas de design RESTful, conforme Richardson et al. (2007) e Madden (2020).

As implicações práticas desses resultados são vastas. A redução da latência nas consultas melhora diretamente a experiência do usuário final, tornando as aplicações mais responsivas e eficientes. O desacoplamento entre as cargas analíticas e operacionais aumenta a escalabilidade do sistema, permitindo que ele suporte um volume crescente de dados e usuários sem comprometer o desempenho. A padronização do acesso aos dados via API REST e a robustez dos mecanismos de autenticação e validação contribuem para a segurança e a manutenibilidade do sistema a longo prazo. A capacidade de filtrar e estruturar dados de forma mais eficiente otimiza a utilização dos recursos computacionais e fornece uma base sólida para a tomada de decisões estratégicas.

Como melhorias futuras, a evolução para materialização de dados em tempo quase real, o uso de cache para otimizar o desempenho de leitura, a implementação de maior observabilidade (monitoramento e logs) e o amadurecimento contínuo das práticas de engenharia são aspectos cruciais para garantir a escalabilidade e a robustez contínuas da arquitetura. Adicionalmente, torna-se essencial a ampliação dos testes de segurança, incluindo validações de autorização, proteção contra vulnerabilidades conhecidas (OWASP Top 10) e testes de carga focados em cenários críticos. Essas medidas adicionais assegurarão a integridade, confidencialidade e disponibilidade do sistema, consolidando a arquitetura proposta como uma solução tecnológica avançada e sustentável.