Performance Evaluation of REST and GraphQL API Models in

Microservices Software Development Domain

Mohamed S. M. Elghazal

, Adel Aneiba

2 a

and Essa Q. Shahra

2 b

Faculty of Information Technology Department of Computer Networks & Communications Department, University of

Benghazi, Benghazi, Libya

Faculty of Computing, Engineering and Built Environment, Birmingham City University, Birmingham B4 7RQ, U.K.

Keywords:

REST API, GraphQL AP, Microservice, Software Development.

Abstract:

This study presents a comprehensive comparative analysis of REST and GraphQL API models within the

context of microservices development, offering empirical insights into the strengths and limitations of each

approach. The research explores the effectiveness and efﬁciency of GraphQL versus REST, focusing on their

impact on critical software quality metrics and user experience. Using a controlled experimental setup, the

study evaluates key performance indicators, including response time, data transfer efﬁciency, and error rates.

The ﬁndings reveal that REST APIs demonstrate superior memory efﬁciency and faster response times, partic-

ularly under high-load conditions, making them a reliable choice for performance-critical microservices. On

the other hand, GraphQL excels in offering greater ﬂexibility for data retrieval, but exhibits higher response

times and higher error rates when handling complex queries. This research provides a nuanced understand-

ing of the trade-offs between the REST and GraphQL API interaction models, offering actionable guidance

to developers and researchers in selecting the optimal API model for microservice-based applications. The

insights are particularly valuable for balancing considerations such as performance, ﬂexibility, and reliability

in real-world implementations.

1 INTRODUCTION

In distributed systems, an application programming

interface (API) allows distributed devices or services

to exchange data regardless of operating system type

(Efuntade et al., 2023). For example, an API allows

any system to exchange the data and functionality

of its services with other systems, devices, or even

other applications within an organisation. As a result,

organisations are increasingly sharing data, services,

and sophisticated resources. This communication can

take place locally, with external partners, or with the

public. APIs are commonly used for the exchange of

text, media, and more (Simon, 2024). Massive and

complicated software products are groups of loosely

linked services in a microservice architecture. Every

service can be hosted separately from the others and is

focused only on achieving one goal, excelling at that

task (Wells, 2024). Figure 1 shows that a microser-

vice architecture is a collection of loosely linked ser-

vices that can be deployed independently, each fo-

https://orcid.org/0000-0002-8021-445X

https://orcid.org/0000-0002-3668-6230

cused on achieving speciﬁc business goals. The mi-

croservice architectural style is deﬁned as a method of

designing software as a collection of discrete services,

each of which is executed in its own process and com-

municates through minimal means, most commonly

an API for HTTP resources (S

oylemez et al., 2024).

These services are aligned with business characteris-

tics and can be deployed independently using fully au-

tomated release tools. Various approaches have been

proposed to increase the efﬁciency of data processing,

some focusing on the forms of requests and responses,

while others optimize the number of queries made

over the network. A recent development is the use

of a declarative data query approach, where client ap-

plications specify the data they need, improving com-

munication with the server to retrieve data more efﬁ-

ciently (Acharya, 2024). Service providers and most

software engineers have embraced the REST archi-

tectural style, largely due to its ease of use compared

to previous web performance standards such as SOAP

and RPC. Moreover, the success of REST can be at-

tributed to the constraints imposed on how service

components are built, potentially beneﬁting the over-

Elghazal, M. S. M., Aneiba, A. and Shahra, E. Q.

Performance Evaluation of REST and GraphQL API Models in Microservices Software Development Domain.

DOI: 10.5220/0013729900003985

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Web Information Systems and Technologies (WEBIST 2025), pages 83-91

ISBN: 978-989-758-772-6; ISSN: 2184-3252

all system when such constraints are applied (Singh

et al., 2024).

gRPC is a high-performance framework that en-

ables applications built using different technologies

to communicate seamlessly. It is based on the con-

cept of deﬁning a service and the methods that can

be called remotely, along with their input parameters

and output formats. It originated from Google’s in-

ternal project, called Stubby, which was designed for

fast and efﬁcient inter-service communication. gRPC

builds on these principles, bringing them to the wider

developer community as an open source solution.

(Levandoski et al., 2024). In 2012, Facebook recog-

nized the need to rebuild its native mobile apps, which

were initially thin wrappers around mobile website

views. A REST server existed, but performance was

poor, and the apps frequently crashed. Developers

sought to transform how data was delivered to client

apps. Lee Byron, Nick Schrock, and Dan Schafer

led the development of GraphQL, a query language

that allows client/server applications to specify the ca-

pabilities and requirements of data models (Sheltami

et al., 2018). GraphQL aims to improve the way con-

sumers interact with remote systems by addressing

several limitations faced by developers working with

REST APIs. For instance, GraphQL allows clients

to request only the data they need, whereas REST

clients often have to make multiple requests to gather

the necessary data (Vadlamani et al., 2021).

GraphQL is a distinct and entirely new method

for interacting with APIs. It is an API query and in-

formation retrieval approach that is open-source. It

provides a customizable, query-based language for

interacting with APIs, offering ﬂexibility and a sin-

gle endpoint. Software components using GraphQL

communicate with the server only to retrieve the spe-

ciﬁc data they request, with queries designed to inter-

act with the web for exactly what is needed—nothing

more. GraphQL was publicly released in 2015 as an

alternative to existing REST services. On November

7, 2018, Facebook handed over the development of

GraphQL to the newly established GraphQL Foun-

dation, which is managed by the non-proﬁt Linux

Foundation. As seen, the tech sector is continuously

evolving, prompting developers to ﬁnd solutions that

balance ﬂexibility and functionality. While REST

APIs offer simplicity and familiarity, their rigid struc-

ture can become problematic. In REST, the API

provider dictates what data is sent, often leading to

over-fetching or under-fetching (Leng et al., 2024).

This model worked in the past, but the rise of com-

plex, client-driven applications necessitates a differ-

ent approach.

GraphQL addresses the shortcomings of REST by

Figure 1: Cloud computing services model.

empowering clients with control over data retrieval.

Clients can specify exactly what data they need in a

single query, which is crucial in dynamic tech envi-

ronments. This ﬂexibility can improve application

performance, streamline development, and enhance

API self-documentation. However, it is important to

recognize the added complexity of GraphQL, poten-

tial security risks, and the need for custom caching

solutions.

The aim of this study is to conduct a comprehen-

sive comparative analysis of REST and GraphQL API

models within the context of microservices develop-

ment, providing empirical insights into the strengths

and limitations of each approach.

This paper is organized as follows: Section 2 re-

views the related work. Section 3 introduces the pro-

posed system model. Section 4 discuss the implemen-

tation and presents the results. Finally, Section 5 con-

cludes the paper.

2 RELATED WORK

GraphQL is a modern class of web-based data access

interfaces that offers an alternative to REST-based in-

terfaces. Due to its advantages over REST, GraphQL

has gained signiﬁcant attention and has been adopted

by a growing number of users since its ofﬁcial launch

(Hartig and P

erez, 2017). Some research studies

have evaluated the performance of both REST and

GraphQL, but many of these studies rely on sim-

ple software development implementations, result-

ing in either ambiguous outcomes or basic network

service functions being tested, such as reading, in-

serting, modifying, and removing data (Mikuła and

Dzie

nkowski, 2020). The results demonstrated that

both services performed equally well in adding, mod-

ifying, and removing data. However, under high

load, performance variations were observed for dis-

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

play functions. While GraphQL may not consis-

tently outperform REST in scenarios involving over-

fetching, it demonstrates comparable performance for

single requests, positioning it as a viable alternative

to REST. Furthermore, in cases of under-fetching,

GraphQL proves to be more efﬁcient than REST, as

it allows clients to retrieve precisely the data they

need in a single query. In environments where under-

fetching occurs frequently, GraphQL emerges as a

more practical and efﬁcient API architecture com-

pared to REST (Vadlamani et al., 2021).

Authors in (Lawi et al., 2021) found that REST

was 51% faster than GraphQL when evaluating the

performance of the two systems in a monolithic archi-

tectural application . However, this result is speciﬁc

to monolithic architectures. C. Pautass et al. in (Pau-

tasso et al., 2008) attempted to compare GraphQL and

REST but did not consider the microservices domain.

When microservices are not fully considered, conclu-

sions about REST can be questionable, as an architec-

ture style is deﬁned by the combination of constraints,

not just individual ones. Metrics are implementation-

dependent and, thus, not always suitable for judging

performance across different domains. In (Brito and

Valente, 2020), they involved 22 graduate and under-

graduate students, aimed to compare the effort and

time required to develop queries for a web service us-

ing REST and GraphQL. The experiment took place

in a controlled setting, with participants randomly as-

signed to either the REST or GraphQL group. The

results indicated that implementing remote service

queries using REST required signiﬁcantly more ef-

fort than with GraphQL, particularly for complex end-

points and multiple inputs, leading to increased devel-

opment time and effort.

Interestingly, the experiment also showed that

even participants with no prior knowledge of

GraphQL could easily implement queries, suggest-

ing that GraphQL has a lower learning curve com-

pared to REST, making it more accessible to devel-

opers (Amareen et al., 2024). However, one limita-

tion of the experiment was the lack of consideration

for microservices as a constraint. Brito argues that

this limitation is not signiﬁcant since most developers

work with monolithic architectures. Nevertheless, the

results could differ if microservices were taken into

account. In (Erlandsson and Remes, 2020) Brito’s

experiment provides valuable insights into the rela-

tive merits of REST and GraphQL, suggesting that

GraphQL is a more efﬁcient and easier-to-use option

for developing remote service queries. However, it is

important to note that these ﬁndings may not be gen-

eralizable to all development contexts. Despite these

limitations, the experiment provides valuable insights

into the relative merits of REST and GraphQL. The

results suggest that GraphQL is a more efﬁcient and

easier-to-use option for developing remote service

queries. The asynchronous JavaScript and XML apps

vant here. Their work connects to Single Page Appli-

cations (SPAs) (Mesbah and Van Deursen, 2007), the

successors to what they referred to as ”AJAX applica-

tions,” which often utilize GraphQL. They precisely

deﬁne factors to consider when developing such apps

using the REST method, such as delta communica-

tion. However, rather than viewing these systems as

variations of existing models, they propose a new ar-

chitectural style that addresses multiple factors previ-

ously covered by older models. Systems using SPAs

can be seen as composites, for example, employing

the Model-View-Controller (MVC) style for the front

end and REST for the backend. Shaw et al. (Shaw and

Clements, 1997) Presents a classiﬁcation of architec-

tural styles based on their fundamental elements, in-

cluding components and connectors, as well as their

handling of control mechanisms, data management,

and the interplay between control and data aspects.

However, this classiﬁcation is disconnected from the

speciﬁc requirements of applications, focusing only

on technical features like the layout or structure of

the ﬁnal system. This makes it difﬁcult for a designer

to choose an architecture, and thus, their classiﬁca-

tion methodology is not appropriate for comparing

GraphQL and REST models, as it does not offer guid-

ance on when to use each for creating an API. Vohra

and Manuaba This research aims to ﬁll this gap by

conducting a quantitative comparison of REST and

GraphQL in a scalable microservices environment.

It will explore performance under real-world condi-

tions, including complex queries and varying levels

of concurrency, providing developers with the empir-

ical data necessary to make informed decisions about

API models in microservices.

Authors in (Vohra and Manuaba, 2022) ex-

plored performance comparisons between REST and

GraphQL within a microservices architecture frame-

work, using a freelance marketplace as their testbed.

They employed Ocelot for REST and HotChocolate

for GraphQL as gateways, using ”JMeter” to simu-

late various user scenarios (Niswar et al., 2024). Per-

formance parameters like average response time and

throughput were analyzed to highlight differences be-

tween REST and GraphQL under diverse scenarios.

While they found similar performance for POST and

PUT queries, signiﬁcant discrepancies arose in GET

queries that retrieved data from multiple services. De-

spite the valuable insights from Vohra and Manuaba’s

study, several limitations must be considered. Firstly,

Performance Evaluation of REST and GraphQL API Models in Microservices Software Development Domain

the study was conducted in a local system rather

than a cloud-based environment, which could restrict

scalability and real-world applicability. Secondly,

the simpliﬁed freelance marketplace scenario might

not fully capture the complexity of real-world mi-

croservices architectures, where interconnected ser-

vices of varying complexities could affect REST and

GraphQL APIs differently. Lastly, the reliance on a

limited number of predeﬁned test cases might con-

strain the comprehensiveness of the ﬁndings, poten-

tially missing a full range of scenarios encountered in

real-world applications. Despite signiﬁcant theoreti-

cal comparisons between REST and GraphQL, empir-

ical research on their performance within microser-

vices architectures remains limited. Existing stud-

ies often focus on monolithic architecture and sim-

ulated environments, which do not accurately reﬂect

the complexities of real-world distributed systems.

3 PROPOSED SYSTEM MODEL

The system architecture is built to compare the per-

formance of REST and GraphQL APIs model in

a microservices environment. Both the REST and

GraphQL services are developed using Go (Golang)

and utilize the GORM library to interact with a cen-

tralized PostgreSQL database. The architecture con-

sists of three key layers:

1. REST Service Layer: It interacts with the Post-

greSQL database using GORM to perform vari-

ous database operations. The REST API exposes

multiple endpoints that allow clients to request re-

sources or perform operations on data.

2. GraphQL Service Layer: Like the REST service,

it communicates with the PostgreSQL database

using GORM, but provides more ﬂexibility in

terms of data fetching, allowing clients to deﬁne

complex queries and mutations.

3. Data Layer: A PostgreSQL database serves as the

shared data layer for both REST and GraphQL

services. This setup ensures consistency in data

management and allows for a fair comparison of

the two services’ performance when interacting

with the same data source.

The proposed system model is Illustrated in Figure

2, which outlines the ﬂow of communication between

different system components. The system is tested

using various tools such as K6 for load testing and

Postman for manual testing. A Python script is em-

ployed for analysis, generating insights into perfor-

mance metrics like response time, memory consump-

tion, and error rates under different testing scenarios.

Figure 2: Proposed system model.

The results are analyzed to compare the efﬁciency and

scalability of both API models within the same mi-

croservices architecture.

4 EXPERIMENT SETUP AND

ANALYSIS PROCEDURES

4.1 Experiment Setup

1. Microservices Development: Two microservices

were implemented, each employing a distinct ar-

chitectural style—one based on REST and the

other on GraphQL. Both services were devel-

oped in Golang, leveraging its performance and

efﬁciency for backend development, and inte-

grated with PostgreSQL to provide robust and

scalable data management across both implemen-

tations. The microservices and databases were

deployed on separate virtual machines running

Ubuntu 22.04 LTS, each provisioned with 4 vC-

PUs, 8 GB RAM, and 50 GB SSD storage. These

machines were connected over a dedicated giga-

bit Ethernet network to minimize latency and en-

sure consistent throughput during testing. This

deployment approach addressed limitations iden-

tiﬁed in earlier work that relied solely on local,

single-machine tests, allowing for a more realistic

evaluation of distributed system performance.

2. Performance Testing Framework: Testing was

conducted using the Grafana K6 framework,

which enabled the simulation of real-world usage

scenarios to evaluate system performance. The

tests scaled up to 1,000 Virtual Users (VUs), ef-

fectively simulating varying levels of user load to

ensure the microservices could handle diverse op-

erational demands.

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

3. Test Scenarios: The performance evaluation was

designed to assess the system under varied op-

erational loads while accounting for differences

in data-retrieval behavior between REST and

GraphQL. Notably, REST often required multi-

ple requests to retrieve the same data due to un-

derfetching. For example, in the Heavy Con-

sumer Scenario, a REST client typically made two

sequential requests of 150bytes each, whereas

GraphQL could retrieve the equivalent dataset in

a single 300-byte query. In some cases, REST

responses also included unused ﬁelds (overfetch-

ing), leading to slightly larger payload sizes than

strictly necessary. These distinctions are impor-

tant when comparing network utilization, latency,

and backend workload.

• The Light Consumer Scenario focused on read-

intensive operations, simulating data fetching

with up to 1,000 Virtual Users (VUs) ramping

up in one minute, holding steady for 30 sec-

onds, and then gradually ramping down. This

scenario aimed to assess API efﬁciency in man-

aging concurrent read requests.

• Concentrated on write-intensive operations,

starting two minutes into the test and follow-

ing the same ramping proﬁle as the Light Con-

sumer Scenario. It measured latency and error

rates during peak insertion loads. Network pay-

load sizes were comparable between REST and

GraphQL for writes, as these operations typi-

cally involved a single structured request.

• Emphasized complex data-retrieval involving

nested or relational queries. Beginning at the

four-minute mark, this scenario highlighted a

key difference: REST often required multi-

ple endpoint calls (e.g., two × 150-byte re-

quests) to assemble the complete dataset, while

GraphQL could perform the same retrieval in a

single composite query ( 300bytes). This al-

lowed direct analysis of query efﬁciency and

backend processing costs.

• Focused on frequent modiﬁcations to existing

data, starting six minutes into the test with the

same ramping structure. While both REST and

GraphQL updates were typically single-request

operations, REST payloads tended to contain

some redundant data ﬁelds due to overfetching

in update responses. This scenario evaluated

efﬁciency, consistency, and error management

under high update loads.

4.2 Analysis Procedures

1. Key Metrics Evaluated

Table 1: REST API vs. GraphQL API results comparison.

Metric REST API GraphQL API

Average

Request

Duration

247.17 ms 915.14 ms

Error Rate

6.86%

15,462

failed out

225,262

requests

5.85%

8,613

failed out

138,492

requests

Requests

Completed

225, 262

471 requests

/second

147,327

312 request

/second

Request

Sending

Duration

1.23 ms (avg),

24.86 second

(max)

477.14 Mic

sec(avg),

1.74 seconds

(max)

Request

Receiving

Duration

44.46 ms(avg),

1 minute,

3 seconds

1.64 ms (avg),

3.96 seconds

(max)

Total VUs

1,000 max

VUs

1,000 max VUs

Test Duraion 8 minutes 8 minutes

• Response Time: Measures efﬁciency in deliv-

ering prompt results under varying loads.

• Memory Consumption: Tracks resource usage

to evaluate scalability under high-demand con-

ditions.

• Error Rate: Monitors system reliability, stabil-

ity, and ability to handle complex queries with-

out failure.

2. Performance Assessment Goals

• Provide a comprehensive evaluation of the sys-

tem’s using the key metrics evaluation men-

tioned above. .

• Identify the suitability of the microservices for

high-demand environments.

5 RESULTS

Table 1 provides a side-by-side comparison of the

REST and GraphQL APIs outputs aspects:

5.1 Individual Metric

The Average Request Duration is another critical met-

ric that highlights the efﬁciency of both API mod-

els. As shown in Figure 3, the average request du-

ration for GraphQL is signiﬁcantly higher than that of

Performance Evaluation of REST and GraphQL API Models in Microservices Software Development Domain

Figure 3: Average request duration by API model.

REST, with GraphQL averaging around 850 ms com-

pared to REST’s average of approximately 250 ms.

This substantial difference can be attributed to the in-

creased complexity of GraphQL queries, which often

involve fetching nested and speciﬁc data structures

that require more server-side processing time. REST,

by contrast, operates with predeﬁned endpoints that

are optimized for quicker data retrieval, leading to

lower request duration. The longer request duration

in GraphQL demonstrates a trade-off between ﬂexi-

bility and performance. While GraphQL offers more

detailed and precise data querying capabilities, this

comes at the cost of increased server-side process-

ing time, especially when handling complex queries.

REST, with its simpler and more straightforward data

fetching mechanism, is able to provide faster response

times, making it more suitable for applications where

low-latency interactions are critical.

Figure 4: Average Request Size of Rest and GraphQL Mod-

els.

Figure 4, shows a signiﬁcant difference in Average

Request Size between REST and GraphQL. REST re-

quests were smaller on average, with sizes typically

around 150 bytes. In contrast, GraphQL requests

were more than twice as large, averaging over 300

bytes. This increase in size for GraphQL is due to its

ability to allow clients to request complex and nested

data in a single query. While REST requests are gen-

erally simpler and more streamlined due to the ﬁxed

structure of endpoints, GraphQL’s ﬂexibility comes

at the cost of larger payloads. This ﬁnding suggests

that while GraphQL offers greater query ﬂexibility,

it may introduce inefﬁciencies in terms of network

bandwidth when dealing with large or frequent re-

quests.

Figure 5: Data received comparison between the two mod-

els.

Figure 5, illustrated Total Data Received by the

client from the server also varied signiﬁcantly be-

tween REST and GraphQL. REST APIs received

far more data, with the total data received near-

ing 4 GB, while GraphQL received signiﬁcantly less

data—close to a few hundred MB. This disparity is

primarily due to the over-fetching inherent in REST,

where endpoints return a ﬁxed set of data regardless

of how much is actually needed by the client. In con-

trast, GraphQL’s ability to request only the data that

is required leads to smaller data transfers, particu-

larly in complex queries where only a subset of ﬁelds

is needed. This result highlights the efﬁciency of

GraphQL in reducing unnecessary data transmission,

making it more suitable in bandwidth-constrained en-

vironments.

Figure 6: Error rate comparison between the two API mod-

els.

Figure 6, presents the Error Rate comparison be-

tween REST and GraphQL. REST showed a slightly

higher error rate, around 7%, while GraphQL’s error

rate was slightly lower, approximately 6%. This dif-

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

ference suggests that REST experiences more chal-

lenges when handling high trafﬁc or more complex

operations. GraphQL’s ability to handle more speciﬁc

queries might reduce the likelihood of errors, as it al-

lows clients to retrieve exactly what they need, reduc-

ing the complexity of server-side operations. How-

ever, it is important to note that this difference is rela-

tively small, and both API models performed reliably

under typical load conditions.

5.2 Time Series Analysis for REST and

GraphQL API Models

Figure 7: Comparison of Data Received (REST vs.

GraphQL).

The data received by the REST and GraphQL APIs

during the performance tests demonstrates the differ-

ent approaches each API takes in handling data re-

trieval. As shown in Figure 7, the REST API con-

sistently processes larger volumes of data compared

to GraphQL. This is a direct result of REST’s static

nature, where predeﬁned endpoints often return all

available data ﬁelds, regardless of whether the client

requires them. In contrast, GraphQL’s ﬂexibility al-

lows clients to specify exactly what data they need,

reducing the amount of unnecessary data transferred.

This observation highlights the efﬁciency of

GraphQL in minimising data transfer, which is par-

ticularly advantageous in bandwidth-constrained en-

vironments or applications where only partial data is

frequently needed. However, REST’s approach can

be beneﬁcial in scenarios where full data responses

are consistently required, as it simpliﬁes server-side

implementation and reduces client-side logic.The vol-

ume of data handled by each API model during the

performance tests, highlighting the more efﬁcient data

transfer exhibited by GraphQL in complex querying

scenarios.

The comparison of data sent between the REST

and GraphQL APIs reveals similar trends to the data

received metrics. The REST API tends to send more

data, as it returns complete responses based on pre-

deﬁned structures. GraphQL, on the other hand, ex-

hibits more efﬁcient data transfer by sending only the

data explicitly requested by theclient. This leads to a

smaller data footprint in GraphQL, especially in com-

plex scenarios where clients can avoid fetching un-

necessary ﬁelds.

This characteristic of GraphQL presents a clear

advantage in applications where precise data fetch-

ing is required, such as mobile apps or environments

with limited resources. However, the simplicity of

REST’s data transmission model makes it more pre-

dictable and easier to manage in scenarios where uni-

form data payloads are necessary. As shown in Fig-

ure 8, the amount of data sent through the REST and

GraphQL APIs demonstrates a signiﬁcant contrast,

particularly when handling requests involving mul-

tiple nested data structures. The Figure emphasizes

GraphQL’s capability to send precise data based on

client requirements, unlike REST, which often results

in over-fetchin.

Figure 8: Comparison of Data Sent (REST vs. GraphQL).

The error rates observed during testing indicate

that GraphQL encounters more frequent errors per

second compared to REST, particularly under heavy

load and when resolving complex, nested queries.

This is largely due to the additional computational

overhead required by GraphQL to dynamically re-

solve requests and gather data from multiple sources.

In contrast, REST’s simpler, more linear request-

response model results in fewer errors, making it

more reliable under high-stress conditions.The fre-

quency of errors encountered per second by each API

model is visualized in Figure 9. The results demon-

Performance Evaluation of REST and GraphQL API Models in Microservices Software Development Domain

Figure 9: Comparison of errors per second (REST vs.

GraphQL)).

strates that GraphQL, though more ﬂexible, tends

to generate more errors under higher loads, espe-

cially when dealing with intricate data queries. This

difference underscores the importance of optimizing

GraphQL resolvers and schema design to mitigate er-

ror rates in production environments. While GraphQL

offers ﬂexibility, it requires careful management to

avoid performance bottlenecks and error spikes dur-

ing peak usage. REST, with its more robust error

handling under load, is better suited for applications

where reliability is prioritized over ﬂexibility. The re-

quests per second (RPS) metric provides insight into

the throughput capabilities of each API. The REST

API consistently handles a higher number of requests

per second compared to GraphQL. This is expected,

given REST’s simpler request-response model, where

requests are statically deﬁned and require less com-

putational overhead to fulﬁll. In contrast, GraphQL’s

dynamic nature, where the client deﬁnes the shape of

the response, introduces additional processing time,

reducing its overall memory.

This observation suggests that REST is better

suited for high-throughput scenarios where perfor-

mance and scalability are critical. GraphQL, while

capable of handling complex queries, may struggle

to maintain high RPS in applications with intense

trafﬁc unless optimizations are made to streamline

query resolution. For developers, this highlights the

trade-off between ﬂexibility and performance in API

design, with REST being the preferred option for

performance-critical applications.

The comparative analysis shows that REST han-

dles a higher volume of requests per second more ef-

ﬁciently, while GraphQL’s performance ﬂuctuates de-

pending on the complexity of the queries being pro-

cessed, as illustrated in Figure 10.

Figure 10: Comparison of requests per second (REST vs.

GraphQL).

6 CONCLUSION

This study presented a comprehensive and empiri-

cal evaluation of REST and GraphQL API models

within the dynamic landscape of microservices de-

velopment. The primary objective was to provide a

detailed comparison of these two paradigms based

on critical performance metrics, including response

time, memory consumption, and error rates. Through

a series of meticulously designed experiments that

leveraged real-world scenarios in a social media sys-

tem, this research effectively highlighted the unique

strengths and limitations of each API model in man-

aging complex data interactions. The experimental

results revealed that REST consistently demonstrated

superior performance in terms of average request du-

ration and error rates, especially under high-load con-

ditions, underscoring its suitability for performance-

critical applications. Conversely, GraphQL excelled

in offering a signiﬁcantly higher degree of ﬂexibility

in data fetching, allowing for more granular and pre-

cise data retrieval. This capability reduces issues such

as over-fetching or under-fetching, enhancing the de-

veloper experience in applications where precise data

control is a priority. The ﬁndings of this study of-

fer valuable practical insights for both developers and

researchers. By presenting robust performance data

and clearly articulating the trade-offs between REST

and GraphQL, the research provides actionable guid-

ance on selecting the most appropriate API model for

microservices-based systems. This work enriches the

growing body of knowledge on API technologies and

empowers the development community to make in-

formed decisions tailored to real-world performance

demands and speciﬁc system requirements.

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

REFERENCES

Acharya, K. (2024). Chat application through client

server management system project. Authorea.

July 29, 2024. DOI: https://doi. org/10.22541/au.

172228527.74316529/v1.

Amareen, S., Dector, O. S., Dado, A., and Bosu, A. (2024).

Graphql adoption and challenges: Community-driven

insights from stackoverﬂow discussions. arXiv

preprint arXiv:2408.08363.

Brito, G. and Valente, M. T. (2020). Rest vs graphql: A con-

trolled experiment. In 2020 IEEE international con-

ference on software architecture (ICSA), pages 81–91.

IEEE.

Efuntade, O. O., Efuntade, A. O., and FCIB, F. (2023).

Application programming interface (api) and man-

agement of web-based accounting information system

(ais): Security of transaction processing system, gen-

eral ledger and ﬁnancial reporting system. Journal of

Accounting and Financial Management, 9(6):1–18.

Erlandsson, P. and Remes, J. (2020). Performance compar-

ison: Between graphql, rest & soap.

Hartig, O. and P

erez, J. (2017). An initial analysis of face-

book’s graphql language.

Lawi, A., Panggabean, B., and Yoshida, T. (2021). Eval-

uating graphql and rest api services performance in a

massive and intensive accessible information system.

computers 2021, 10, 138.

Leng, J., Guo, J., Xie, J., Zhou, X., Liu, A., Gu, X.,

Mourtzis, D., Qi, Q., Liu, Q., Shen, W., et al. (2024).

Review of manufacturing system design in the inter-

play of industry 4.0 and industry 5.0 (part i): Design

thinking and modeling methods. Journal of Manufac-

turing Systems, 76:158–187.

Levandoski, J., Casto, G., Deng, M., Desai, R., Edara, P.,

Hottelier, T., Hormati, A., Johnson, A., Johnson, J.,

Kurzyniec, D., et al. (2024). Biglake: Bigquery’s evo-

lution toward a multi-cloud lakehouse. In Companion

of the 2024 International Conference on Management

of Data, pages 334–346.

Mesbah, A. and Van Deursen, A. (2007). An architectural

style for ajax. In 2007 Working IEEE/IFIP Confer-

ence on Software Architecture (WICSA’07), pages 9–

9. IEEE.

Mikuła, M. and Dzie

nkowski, M. (2020). Comparison of

rest and graphql web technology performance. Jour-

nal of Computer Sciences Institute, 16:309–316.

Niswar, M., Safruddin, R. A., Bustamin, A., and Aswad,

I. (2024). Performance evaluation of microservices

communication with rest, graphql, and grpc. Interna-

tional Journal of Electronics and Telecommunication,

70(2):429–436.

Pautasso, C., Zimmermann, O., and Leymann, F. (2008).

Restful web services vs.” big”’web services: mak-

ing the right architectural decision. In Proceedings of

the 17th international conference on World Wide Web,

pages 805–814.

Shaw, M. and Clements, P. (1997). A ﬁeld guide to boxol-

ogy: Preliminary classiﬁcation of architectural styles

for software systems. In Proceedings Twenty-First An-

nual International Computer Software and Applica-

tions Conference (COMPSAC’97), pages 6–13. IEEE.

Sheltami, T. R., Shahra, E. Q., and Shakshuki, E. M. (2018).

Fog computing: Data streaming services for mobile

end-users. Procedia computer science, 134:289–296.

Simon, F. M. (2024). Escape me if you can: How ai re-

shapes news organisations’ dependency on platform

companies. Digital Journalism, 12(2):149–170.

Singh, S. P., Mehta, A., and Vasudev, H. (2024). Applica-

tion of sensitivity analysis for multiple attribute deci-

sion making in lean production system. Engineering

Management Journal, pages 1–24.

oylemez, M., Tekinerdogan, B., and Tarhan, A. K. (2024).

Microservice reference architecture design: A multi-

case study. Software: Practice and Experience,

54(1):58–84.

Vadlamani, S. L., Emdon, B., Arts, J., and Baysal, O.

(2021). Can graphql replace rest? a study of their

efﬁciency and viability. In 2021 IEEE/ACM 8th In-

ternational Workshop on Software Engineering Re-

search and Industrial Practice (SER&IP), pages 10–

17. IEEE.

Vohra, N. and Manuaba, I. B. K. (2022). Implementation

of rest api vs graphql in microservice architecture. In

2022 International Conference on Information Man-

agement and Technology (ICIMTech), pages 45–50.

IEEE.

Wells, S. (2024). Enabling microservice success: managing

technical, organizational, and cultural challenges. ”

O’Reilly Media, Inc.”.

Performance Evaluation of REST and GraphQL API Models in Microservices Software Development Domain