Fernanda Tiemi Yamanishi; Enderson Luiz Pereira Júnior

DOI: 10.22167/2675-6528-202600801

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

Resumo

A comunicação eficiente entre aplicações móveis e serviços é crucial para otimizar o desempenho e o uso de recursos, sendo a escolha da tecnologia de API um fator determinante. Diante da ausência de consenso na literatura e da escassez de estudos sobre APIs em aplicações multiplataforma, comparou-se o desempenho de APIs REST e GraphQL quando consumidas por uma aplicação desenvolvida com .NET MAUI. As métricas consideradas incluíram tempo de resposta, taxa de transferência, uso de CPU e consumo de memória. Para isso, realizou-se uma pesquisa experimental, na qual se desenvolveram duas APIs (REST e GraphQL) e se submeteram a três experimentos, abrangendo cenários de “overfetching”, “underfetching” e operações de escrita. Os dados foram coletados por meio de logs da aplicação cliente e do monitoramento de contêineres Docker, permitindo a análise estatística. Os resultados indicaram que o GraphQL apresentou melhor desempenho no tempo de resposta em cenários com maior volume de dados, mas com maior consumo de memória. O REST, por sua vez, mostrou-se mais eficiente em cenários mais simples e, em alguns casos, na taxa de transferência. O uso de CPU permaneceu baixo em ambas as abordagens, sem diferenças significativas. Concluiu-se que nenhuma das abordagens se mostrou superior em todas as métricas, e a escolha ideal depende do contexto da aplicação, considerando o volume de dados, a complexidade das consultas e os requisitos de desempenho.

Palavras-chave: Comunicação cliente-servidor; Desenvolvimento de aplicativos móveis; GraphQL; Integração de sistemas; REST.

1. Introdução

O desenvolvimento de aplicações móveis constitui uma área de pesquisa relevante, em razão da contínua expansão desse mercado e da crescente demanda por soluções eficientes. Nesse cenário, o desenvolvimento de aplicativos pode seguir dois modelos predominantes: o nativo, que envolve a criação de versões específicas para cada sistema operacional, e o multiplataforma. A abordagem multiplataforma tem ganhado destaque por permitir a construção de aplicações para diversos sistemas operacionais a partir de um único código-fonte, o que resulta em redução de custos e otimização do tempo de desenvolvimento, mantendo um desempenho comparável ao das aplicações nativas. Entre as tecnologias que impulsionam essa modalidade, destaca-se o .NET MAUI, um “framework” lançado pela Microsoft em 2022, que facilita o compartilhamento de código, incluindo a interface gráfica e as regras de negócio, entre diferentes plataformas (Jošt e Taneski, 2025; Nawrocki et al., 2021).

No contexto do desenvolvimento de aplicações móveis, a comunicação eficiente entre sistemas é um fator crítico para o desempenho e a utilização de recursos. As Application Programming Interfaces (APIs) desempenham um papel fundamental na integração de sistemas, atuando como pontes que permitem a troca de dados e funcionalidades entre diferentes componentes de software. A escolha da tecnologia de API é, portanto, uma decisão estratégica que impacta diretamente a performance da aplicação e a experiência do usuário.

Entre as principais abordagens para o desenvolvimento de APIs, destaca-se o Representational State Transfer (REST). REST é um estilo arquitetural para sistemas distribuídos em rede, fundamentado em princípios como a comunicação cliente-servidor, a interface uniforme e a ausência de estado (Fielding, 2000). As APIs REST expõem recursos como entidades de domínio, acessíveis por meio de Uniform Resource Identifiers (URIs) e manipulados através de métodos HTTP, como GET para leitura e POST para escrita. Essa abordagem é amplamente utilizada e valorizada pela sua simplicidade e escalabilidade em muitos cenários de integração (Kamiński et al., 2023; Sayago Heredia et al., 2019).

Paralelamente, o GraphQL emergiu como uma alternativa robusta, sendo uma linguagem de consulta de dados para APIs desenvolvida para otimizar a comunicação entre cliente e servidor (Byron, 2015). Diferentemente do REST, que frequentemente retorna conjuntos fixos de dados, o GraphQL permite que o cliente especifique exatamente quais dados são necessários em uma única requisição. Essa capacidade evita o “overfetching”, onde dados desnecessários são enviados, e o “underfetching”, que exige múltiplas requisições para obter todas as informações desejadas, otimizando o consumo de recursos e o tempo de resposta (Kamiński et al., 2023; Sayago Heredia et al., 2019).

Apesar da relevância dessas tecnologias, a literatura acadêmica ainda carece de um consenso claro sobre qual abordagem de API oferece o melhor desempenho em diferentes contextos, especialmente no que tange a aplicações móveis desenvolvidas com ferramentas multiplataforma. A escassez de estudos comparativos que avaliam o comportamento de APIs REST e GraphQL em conjunto com tecnologias emergentes como o .NET MAUI, lançado recentemente, representa uma lacuna significativa. Essa falta de investigação aprofundada impede que desenvolvedores e arquitetos de software tomem decisões informadas sobre a escolha da tecnologia de API mais adequada para seus projetos.

Diante dessa lacuna e da importância de otimizar a comunicação e o desempenho em aplicações móveis multiplataforma, este trabalho se justifica pela necessidade de fornecer subsídios técnicos e empíricos para a tomada de decisão. A escolha entre REST e GraphQL impacta diretamente a eficiência, o uso de recursos e a escalabilidade das aplicações. Assim, o objetivo deste estudo é comparar o desempenho de APIs REST e GraphQL, quando consumidas por aplicações multiplataforma desenvolvidas com .NET MAUI, considerando métricas como tempo de resposta, taxa de transferência, uso de CPU e consumo de memória.

2. Material e Métodos

A pesquisa adotou um caráter exploratório e descritivo, com abordagem metodológica quantitativa, focada na coleta e análise de dados. O delineamento do estudo foi experimental, realizando-se experimentos em ambiente controlado para analisar o comportamento das variáveis, visando comparar desempenho das APIs REST e GraphQL (Gil, 2022).

Previamente à fase experimental, conduziu-se uma revisão bibliográfica em bases de dados como IEEE Xplore e Scopus, utilizando as palavras-chave “REST GraphQL”, “REST GraphQL mobile”, “cross-platform mobile” e “.NET MAUI”. Os estudos subsidiaram a formulação do problema e o plano experimental. Para testar as hipóteses, desenvolveram-se duas APIs, uma REST e outra GraphQL, sobre um domínio de gestão de projetos (projetos e tarefas), consumidas por uma aplicação cliente em .NET MAUI.

O armazenamento de dados utilizou SQLite, integrado via Entity Framework Core. Para um ambiente controlado, as APIs e seus bancos de dados foram executados em contêineres Docker, orquestrados por um arquivo “docker-compose.yaml”. A API REST expôs entidades como recursos via “controllers” e DTOs, processando requisições HTTP (GET e POST) e retornando JSON. A API GraphQL, implementada com HotChocolate (versão 15.1.12) em .NET, expôs o domínio por um “schema” para “queries” e “mutations”, processando requisições, retornando JSON.

A aplicação cliente, desenvolvida em Microsoft Visual Studio Community 2022 (versão 17.14.24) com .NET MAUI e .NET 9.0, foi projetada para consumir ambas as APIs e medir tempo de resposta e taxa de transferência. Adotou-se a arquitetura Model-View-ViewModel (MVVM). Serviços específicos, “ApiRestService” e “ApiGraphQLService”, encapsularam a comunicação. Os testes ocorreram em um emulador Android (Pixel 7 – API 35.0), com Android 15.0, arquitetura x86_64 e 1GB de memória, assegurando condições controladas.

As métricas avaliadas foram tempo de resposta, taxa de transferência, uso de CPU e consumo de memória. Os dados foram obtidos por logs da aplicação cliente (NLog) e monitoramento dos contêineres Docker. O tempo de resposta foi mensurado por “Stopwatch”, e a taxa de transferência calculada pela razão entre volume de dados e tempo. Uso de CPU e memória foram monitorados a cada dois segundos via script. Os dados do servidor foram correlacionados com logs da aplicação por scripts Python, considerando “timestamps”. Cada operação foi executada onze vezes consecutivas, descartando-se a primeira para mitigar interferências iniciais.

Para a análise dos dados, consolidaram-se os resultados de cada métrica, calculando-se média aritmética, desvio padrão, mediana, mínimo e máximo. O primeiro experimento investigou o impacto do “overfetching”. A API REST retornou todos os atributos via GET /projects, enquanto a API GraphQL foi configurada para retornar apenas os campos necessários. Os bancos de dados foram populados com um, quinhentos, mil e dois mil registros.

O segundo experimento avaliou o “underfetching”. A aplicação exibiu dados de um projeto e suas tarefas. A API REST demandou duas requisições (projeto e tarefas separadamente). A API GraphQL obteve esses dados em uma única requisição. Os bancos de dados foram populados com cem projetos, e a quantidade de tarefas por projeto variou entre um, cinquenta e cem, totalizando cem, cinco mil e dez mil registros de tarefas.

O terceiro experimento comparou o desempenho em operações de escrita. Inserções de novos projetos foram realizadas pela tela de cadastro, utilizando o endpoint POST /projects na API REST e uma “mutation” na API GraphQL. Os bancos de dados foram populados com dez projetos, e dez inserções adicionais foram realizadas para cada abordagem. Ferramentas de inteligência artificial, como ChatGPT Go 5.2 e GitHub Copilot com Claude Sonnet 4.5, auxiliaram na resolução de problemas, consulta de bibliotecas, geração de modelo lógico, elaboração de scripts e revisão textual.

3. Resultados e Discussão

A análise do desempenho das APIs REST e GraphQL, consumidas por uma aplicação desenvolvida em .NET MAUI, revelou padrões distintos em relação às métricas de tempo de resposta, taxa de transferência, uso de CPU e consumo de memória. Os experimentos foram projetados para simular cenários de leitura de dados com diferentes volumes e complexidades, além de operações de escrita, permitindo uma comparação abrangente das abordagens. A aplicação cliente foi desenvolvida para interagir com ambas as APIs, registrando os dados de desempenho para posterior análise estatística, que incluiu média, mediana, desvio padrão, e valores mínimo e máximo.

A interface inicial da aplicação, que serviu como ponto de partida para os experimentos, apresentava um botão para acessar a lista de projetos e um interruptor para alternar entre os serviços de API REST e GraphQL. Essa funcionalidade de alternância foi crucial para a execução controlada dos testes, garantindo que as medições fossem realizadas sob as mesmas condições para ambas as tecnologias. Os logs gerados pela aplicação cliente e os dados coletados dos contêineres Docker forneceram as informações necessárias para calcular as métricas de desempenho, assegurando a precisão da coleta de dados.

Experimento 1 – tela com a lista de projetos com nome e descrição

O primeiro experimento focou na avaliação do impacto do “overfetching”, um cenário onde a API REST retorna todos os atributos de uma entidade, mesmo que a aplicação cliente necessite apenas de um subconjunto desses dados. Em contraste, a API GraphQL foi configurada para retornar exclusivamente os campos de nome e descrição dos projetos, conforme solicitado pela aplicação. Os testes foram conduzidos com bancos de dados contendo 1, 500, 1000 e 2000 registros, permitindo observar o comportamento das APIs sob diferentes cargas de dados.

Em relação ao tempo de resposta, observou-se que para cargas reduzidas, como um único registro, a API REST apresentou um tempo médio de 35,4 milissegundos, ligeiramente inferior aos 42,4 milissegundos do GraphQL. Contudo, à medida que o volume de dados aumentou para 500, 1000 e 2000 registros, o GraphQL demonstrou melhor desempenho, com tempos médios de 125,0, 159,2 e 268,8 milissegundos, respectivamente, enquanto o REST registrou 190,2, 250,1 e 316,4 milissegundos. Esse padrão está alinhado com estudos anteriores que indicam a superioridade do GraphQL em cenários com maior volume de dados, embora possa ser inferior em cargas muito baixas (Kamiński et al., 2023; Lawi et al., 2021; Ala-Laurinaho et al., 2022).

A taxa de transferência apresentou um comportamento distinto. A API REST registrou valores médios superiores em todos os cenários, como 5,45 bytes por milissegundo para um registro e 1091,78 bytes por milissegundo para 2000 registros, em comparação com 3,23 e 796,78 bytes por milissegundo do GraphQL, respectivamente. Essa diferença é atribuída ao “overfetching” inerente ao REST, que retorna um volume maior de dados do que o estritamente necessário para a aplicação. Embora a taxa de transferência do REST seja numericamente maior, isso não se traduz necessariamente em maior eficiência, pois grande parte dos dados transmitidos pode ser descartada pelo cliente, como apontado por Quiña-Mera et al. (2022).

O uso de CPU permaneceu em níveis baixos para ambas as abordagens em todos os cenários do Experimento 1, sem uma tendência clara de crescimento ou uma vantagem consistente para qualquer uma das APIs. Os valores médios variaram entre 2,75% e 5,66% para REST e entre 3,10% e 5,13% para GraphQL. Esse resultado sugere que as operações foram predominantemente limitadas por I/O, como acesso ao banco de dados e transferência de dados, e não por processamento computacional intensivo. A ausência de diferenças significativas no uso de CPU pode indicar que o volume de carga utilizado no estudo não foi suficiente para evidenciar variações mais expressivas, diferentemente de outros trabalhos (Lawi et al., 2021).

No que concerne ao consumo de memória, a API GraphQL demonstrou valores consistentemente superiores aos da API REST em todas as cargas de dados. Para um registro, o GraphQL consumiu em média 66,37 MiB, enquanto o REST utilizou 59,39 MiB. Para 2000 registros, o consumo médio do GraphQL foi de 136,23 MiB, contra 130,98 MiB do REST. Esse comportamento sugere uma maior demanda de memória associada ao processamento das “queries” e à resolução do “schema” no GraphQL, que envolve a construção dinâmica das respostas com base nas solicitações do cliente. Essa observação, no entanto, diverge de alguns estudos que encontraram menor consumo de memória no GraphQL em cenários de alta carga (Lawi et al., 2021), possivelmente devido às especificidades do ambiente experimental e ao volume de dados.

Em síntese, no cenário de “overfetching”, o GraphQL apresentou melhor desempenho no tempo de resposta em situações com maior volume de dados, indicando maior escalabilidade. Em contrapartida, o REST demonstrou maior taxa de transferência, embora isso estivesse associado ao envio de dados desnecessários. O uso de CPU não foi um fator diferenciador, permanecendo baixo para ambas. O consumo de memória foi consistentemente maior no GraphQL, provavelmente devido ao processamento adicional necessário para a resolução das consultas. Esses achados reforçam que o GraphQL é mais adequado para cenários que exigem controle fino sobre os dados, enquanto o REST pode ser mais eficiente em contextos mais simples.

Experimento 2 – tela com detalhes do projeto e lista de tarefas

O segundo experimento teve como objetivo avaliar o impacto do “underfetching”, onde a API REST exigiria múltiplas requisições para obter todos os dados necessários para uma tela. Nesse cenário, a aplicação exibia os detalhes de um projeto e sua lista de tarefas associadas. A API REST realizou duas requisições separadas: uma para os dados do projeto e outra para as tarefas. Em contraste, a API GraphQL obteve todos os dados em uma única requisição, demonstrando sua capacidade de agregação de informações.

Os bancos de dados foram populados com 100 projetos, e a quantidade de tarefas por projeto variou entre 1, 50 e 100, resultando em 100, 5000 e 10000 registros de tarefas, respectivamente. Essa variação permitiu analisar o desempenho das APIs sob diferentes níveis de complexidade e volume de dados relacionados. A tela de detalhes do projeto e tarefas ilustrava a necessidade de consolidar informações de diferentes entidades, um cenário comum em aplicações reais.

No que diz respeito ao tempo de resposta, a API GraphQL apresentou consistentemente valores médios e medianos inferiores (melhores) em todos os cenários. Para 100 registros de tarefas, o GraphQL teve um tempo médio de 75,1 milissegundos, enquanto o REST registrou 85,0 milissegundos. Com 10000 registros, o GraphQL manteve um tempo médio de 139,5 milissegundos, significativamente menor que os 246,9 milissegundos do REST. Essa diferença é crucial, pois o GraphQL, ao consolidar múltiplas operações em uma única requisição, reduz a latência e a sobrecarga de comunicação, reforçando sua capacidade de escalabilidade em cenários complexos (Kamiński et al., 2023).

A taxa de transferência no Experimento 2 não mostrou diferenças significativas entre as abordagens em cenários com poucos dados. No entanto, à medida que a carga aumentou, a API REST apresentou uma redução nos valores, enquanto o GraphQL manteve um comportamento mais estável. Para 10000 registros, o GraphQL alcançou uma média de 99,32 bytes por milissegundo, enquanto o REST ficou em 79,43 bytes por milissegundo. Esse resultado pode ser explicado pelo efeito combinado do maior volume de dados transferidos e da necessidade de múltiplas requisições no REST, devido ao “underfetching”, o que impacta negativamente a eficiência da comunicação.

O uso de CPU no Experimento 2, assim como no primeiro, permaneceu baixo para ambas as abordagens, sem diferenças significativas. Os valores médios variaram entre 0,01% e 9,20% para REST e entre 0,02% e 8,76% para GraphQL. Esse comportamento sugere que as operações foram predominantemente limitadas por I/O, especialmente a comunicação com o banco de dados e a transferência de dados pela rede. Embora tenham sido observados picos isolados, possivelmente relacionados ao método de coleta por amostragem, o uso de CPU não se mostrou um fator determinante para a diferenciação de desempenho entre as APIs neste estudo.

Em relação ao consumo de memória, a API GraphQL novamente demonstrou maior consumo em todos os cenários, mantendo o padrão observado no experimento anterior. Para 100 registros, o GraphQL consumiu em média 75,43 MiB, contra 68,07 MiB do REST. Com 10000 registros, o consumo médio do GraphQL foi de 188,86 MiB, enquanto o REST utilizou 174,29 MiB. A baixa variabilidade observada indica estabilidade nas medições e reforça a ideia de que o processamento adicional de “queries” e a resolução de “schema” no GraphQL demandam mais recursos de memória.

Os resultados do segundo experimento indicam que o GraphQL oferece vantagens significativas em cenários de “underfetching”, onde a recuperação de dados complexos e relacionados é necessária. Sua capacidade de consolidar múltiplas operações em uma única requisição resulta em melhor tempo de resposta e maior estabilidade na taxa de transferência para volumes elevados de dados. Embora o consumo de memória seja maior no GraphQL, os benefícios em eficiência de comunicação e desempenho em cenários complexos podem justificar esse custo, especialmente quando a flexibilidade na consulta de dados é um requisito crítico.

Experimento 3 – criação de projeto novo

O terceiro experimento comparou o desempenho das APIs em operações de escrita, especificamente na criação de novos projetos. A aplicação cliente utilizou uma tela de cadastro para inserir dez novos projetos em bancos de dados que já haviam sido populados com dez projetos. Na API REST, a operação foi realizada por meio do endpoint POST /projects, enquanto na API GraphQL, utilizou-se uma “mutation” para a mesma finalidade. Este cenário permitiu avaliar como cada abordagem lida com a persistência de dados.

No que se refere ao tempo de resposta para operações de escrita, a API GraphQL apresentou tempos médios ligeiramente inferiores aos da API REST. O GraphQL registrou um tempo médio de 118,0 milissegundos, enquanto o REST obteve 136,7 milissegundos. Essa diferença, embora existente, foi pouco expressiva, indicando um desempenho semelhante entre as duas abordagens para operações de escrita simples. Esse achado diverge de alguns estudos que identificaram diferenças mais acentuadas (Kamiński et al., 2023; Ala-Laurinaho et al., 2022), mas está em consonância com outros que observaram poucas variações em operações de escrita (Vohra e Manuaba, 2022).

A divergência em relação a outros estudos pode ser explicada por fatores como o ambiente experimental, a forma de implementação das APIs e o baixo volume de dados manipulados. A simplicidade do domínio utilizado também pode ter contribuído para minimizar as diferenças. No GraphQL, o uso de “mutations” pode simplificar o processamento ao permitir o envio apenas dos dados necessários. No REST, a depender da implementação, os endpoints podem exigir objetos mais completos, aumentando o custo de serialização e persistência, o que impacta o tempo total de processamento.

A taxa de transferência no Experimento 3 mostrou que a API REST registrou uma média de 1,23 bytes por milissegundo, enquanto o GraphQL obteve 0,92 bytes por milissegundo. Embora o REST tenha apresentado um valor ligeiramente superior, essa diferença não indica necessariamente maior eficiência, pois a operação de escrita envolve etapas adicionais de processamento e validação das regras de negócio, e o volume de dados retornado pode não ser o único indicador de desempenho relevante neste contexto. A diferença foi pouco expressiva e não sugere uma vantagem clara para nenhuma das abordagens.

O uso de CPU permaneceu baixo em ambas as abordagens para as operações de escrita, com médias de 0,05% para GraphQL e 0,15% para REST. Esse resultado reforça a observação dos experimentos anteriores de que as operações foram predominantemente limitadas por I/O e não exigiram processamento intensivo. A API REST apresentou ligeiramente maior variabilidade, mas as diferenças foram mínimas e não impactaram significativamente a comparação de desempenho. O uso de CPU não se mostrou um fator relevante para diferenciar as abordagens neste cenário.

Quanto ao consumo de memória, a API GraphQL novamente demonstrou um consumo médio superior ao da API REST, com 70,11 MiB contra 59,89 MiB, respectivamente. Embora a diferença tenha sido menos acentuada do que nos experimentos de leitura, o padrão de maior consumo de memória no GraphQL persistiu. Esse comportamento indica que, mesmo em operações de escrita, o processamento adicional associado ao GraphQL, como a validação do “schema” e a manipulação da “mutation”, continua a impactar o uso de memória, ainda que de forma menos pronunciada em cenários mais simples.

Em resumo, os resultados do Experimento 3 indicaram um desempenho semelhante entre as abordagens em operações de escrita. O GraphQL apresentou uma leve vantagem no tempo de resposta, enquanto o REST teve uma ligeira superioridade na taxa de transferência. O uso de CPU não foi um fator relevante, e o consumo de memória permaneceu maior no GraphQL. De modo geral, em cenários de escrita simples, as diferenças de desempenho entre REST e GraphQL tendem a ser reduzidas, e a escolha pode depender de outros fatores como a complexidade do domínio e a necessidade de flexibilidade na manipulação de dados.

A análise comparativa do desempenho das APIs REST e GraphQL em uma aplicação .NET MAUI revelou que nenhuma das abordagens se mostrou universalmente superior em todas as métricas e cenários. O GraphQL demonstrou maior eficiência no tempo de resposta em situações que demandam maior volume de dados ou consultas mais complexas, como nos cenários de “overfetching” e “underfetching”, devido à sua capacidade de reduzir requisições e otimizar a recuperação de dados. Por outro lado, o REST apresentou melhor desempenho em cenários mais simples e com menor volume de dados, e em alguns casos, uma taxa de transferência numericamente maior, embora com o custo de “overfetching”. O uso de CPU permaneceu baixo e não foi um fator diferenciador significativo entre as abordagens, enquanto o consumo de memória foi consistentemente maior no GraphQL, atribuído ao processamento adicional de “queries” e resolução de “schema”. Esses achados indicam uma relação de troca entre a flexibilidade e o controle de dados oferecidos pelo GraphQL e seu maior consumo de recursos, e a simplicidade do REST com suas potenciais ineficiências de dados, sugerindo que a escolha ideal da tecnologia de API depende intrinsecamente do contexto da aplicação, do volume de dados, da complexidade das consultas e dos requisitos de desempenho específicos do projeto.

4. Conclusão

O estudo comparou o desempenho de APIs REST e GraphQL quando consumidas por aplicações multiplataforma desenvolvidas com .NET MAUI, considerando métricas como tempo de resposta, taxa de transferência, uso de CPU e consumo de memória. Verificou-se que o GraphQL demonstrou maior eficiência no tempo de resposta em cenários que demandavam maior volume de dados ou consultas mais complexas, como os de “overfetching” e “underfetching”, ao otimizar a recuperação de dados e reduzir requisições. Em contrapartida, a API REST apresentou melhor desempenho em cenários mais simples e com menor volume de dados, e em alguns casos, uma taxa de transferência numericamente superior, embora associada ao envio de dados desnecessários. O uso de CPU permaneceu baixo e não se mostrou um fator diferenciador significativo entre as abordagens. Contudo, o consumo de memória foi consistentemente maior no GraphQL, atribuído ao processamento adicional de “queries” e à resolução de “schema”.

Esses achados evidenciam uma relação de troca entre a flexibilidade e o controle de dados oferecidos pelo GraphQL e seu maior consumo de recursos, e a simplicidade do REST com suas potenciais ineficiências de dados. A principal contribuição deste estudo reside em fornecer subsídios empíricos para a tomada de decisão na escolha da tecnologia de API mais adequada para projetos de aplicações móveis multiplataforma em .NET MAUI, considerando o contexto da aplicação, o volume de dados, a complexidade das consultas e os requisitos de desempenho específicos. Como limitação, o volume de carga utilizado pode não ter sido suficiente para evidenciar diferenças mais expressivas no uso de CPU, e as especificidades do ambiente experimental podem influenciar os resultados. Sugere-se para estudos futuros a investigação do desempenho dessas APIs em cenários de carga mais elevada, em diferentes plataformas multiplataforma e a análise de fatores como a complexidade do domínio e a manutenção a longo prazo.

Referências Bibliográficas

Ala-Laurinaho, R.; Mattila J.; Autiosalo J.; Hietala J.; Laaki H.; Tammi K. 2022. Comparison of REST and GraphQL interfaces for OPC UA. Computers 11(5): 65

Byron, L. 2015. GraphQL: a data query language. Disponível em: <https://engineering.fb.com/2015/09/14/core-infra/graphql-a-data-query-language/>. Acesso em: 14 out. 2025

Fielding, R. T. 2000. Architectural styles and the design of network-based software architectures. Tese de Doutorado em Informação e Ciência da Computação. Universidade da California, Irvine, CA, Estados Unidos.

Gil, A. C. 2022. Como Delinear uma Pesquisa Experimental. p.81-89. In: Gil, A. C. Como Elaborar Projetos de Pesquisa. 7. Atlas, Barueri, SP, Brasil. Disponível em: https://app.minhabiblioteca.com.br/reader/books/9786559771653/epubcfi/6/10[%3Bvnd.vst.idref%3Dhtml5]!/4/26/3:47[ega%2Cle]>. Acesso em: 19 out. 2025.

Jošt, G.; Taneski, V. 2025. State-of-the-art cross-platform mobile application development frameworks: a comparative study of market and developer trends. Informatics 12(2): 45

Kamiński, Ł.; Kozłowski, M.; Sporysz, D.; Wolska, K.; Zaniewski, P.; Roszczyk, R. 2023. Comparative review of selected internet communication protocols. Foundations of Computing and Decision Sciences 48(1): 39-56.

Lawi, A.; Panggabean, B. L. E.; Yoshida, T. 2021. Evaluating GraphQL and REST API services performance in a massive and intensive accessible information system. Computers 10(11): 138.

Nawrocki, P.; Wrona, K.; Marczak, M; Sniezynski, B. 2021. A comparison of native and cross-platform frameworks for mobile applications. Computer 54(3):18-27.

Quiña-Mera, A.; García, J.M.; Fernández, P.; Vega-Molina, P.; Ruiz-Cortés, A. GraphQL or REST for mobile applications? In: Advanced Research in Technologies, Information, Innovation and Sustainability Second International Conference, 2022, Santiago de Compostela, Espanha. Anais… p.16-30.

Sayago Heredia J.; Flores-García E.; Recalde Solano A. 2019. Comparative analysis between standards oriented to web services: SOAP, REST and GRAPHQL. In: First International Conference on Applied Technologies, 2019, Quito, Pichincha, Equador. Anais… p. 286-300.

Vohra, N.; Manuaba, I. B. K. 2022. Implementation of REST API vs GraphQL in microservice architecture. In: International Conference on Information Management and Technology (ICIMTech), 2022, Semarang, Indonésia. p. 45-50.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy