APIs are the backbone of modern software. Whether you’re syncing microservices or powering frontend applications, how systems communicate can significantly impact speed, scalability, and user experience.
Two widely adopted API paradigms are REST (Representational State Transfer) and gRPC (Google Remote Procedure Call).
Each comes with its own advantages, REST uses HTTP/1.1 and transmits data in text-based formats like JSON or XML, making it widely compatible and easy to debug. gRPC, on the other hand, uses HTTP/2 and Protocol Buffers (protobuf), a compact, binary serialization format optimized for speed and performance. While REST is a go-to for public APIs and quick development, gRPC is better suited for microservices and systems where performance is critical.
This blog will walk you through a performance comparison between REST and gRPC, focusing on two dimensions:
- Handling concurrent requests
- Growing payload sizes
The Experiment Setup
Following image illustrate the system diagram that is designed for the experiment.
For the experiment, Two Spring Boot applications were deployed using Docker and Each protocol was exposed through separate endpoints
- Server A hosted the client application
- Server B hosted the server application
The objective was to evaluate how REST and gRPC perform as response sizes increase and to observe how each architecture handles concurrent requests. To meet these goals, two endpoints were implemented in the client application, as below.
http://IP:PORT/api/data/grpc?array=5&attribute=5
http://IP:PORT/api/data/rest?array=5&attribute=5The image below shows the identical response returned by both endpoints. The attribute query parameter specifies the number of attributes within each object, while the array query parameter determines the number of objects in the response array.
Test 1: Response Time as Payload Size Grows
To evaluate how response size affects response time, both endpoints were called sequentially while incrementally increasing the array and attribute parameters by five, starting from 5 and going up to 250. Application logs were then collected for both REST and gRPC. The logs include the protocol used, response time (in milliseconds), response size (in bytes), and the values of the attribute and array parameters. A few sample log entries are shown below.
app-one_1 | 2025-05-26 11:47:09 [http-nio-8080-exec-4] INFO p.c.d.a.controller.DataController [] – REST Communication – Time=263.643ms, Size=285bytes, Attributes=5, ArraySize=5
app-one_1 | 2025-05-26 11:47:09 [http-nio-8080-exec-5] INFO p.c.d.a.controller.DataController [] – REST Communication – Time=137.773ms, Size=1287bytes, Attributes=10, ArraySize=10
app-one_1 | 2025-05-26 11:50:30 [http-nio-8080-exec-5] INFO p.c.d.a.controller.DataController [] – gRPC Communication – Time=143.557ms, Size=379bytes, Attributes=5, ArraySize=5
app-one_1 | 2025-05-26 11:50:30 [http-nio-8080-exec-6] INFO p.c.d.a.controller.DataController [] – gRPC Communication – Time=146.449ms, Size=1613bytes, Attributes=10, ArraySize=10Afterward, all application logs were exported to a log file, and a line chart was generated using Matplotlib and Seaborn to visualize response time against payload size. The results clearly show that as payload size increases, the response time for REST grows significantly higher compared to gRPC.
Test 2: Handling Concurrent Requests
Next, to assess how both architectural styles handle concurrent requests, a simple Python program was written with the help of ChatGPT. The program sent 20 requests per second for 10 seconds, totaling 200 requests per endpoint. Unlike the previous test, the requests were sent concurrently rather than sequentially. The query parameters were kept constant at a value of 5 throughout the test. As before, server logs were collected for further analysis.
app-one_1 | 2025-05-28 17:10:23 [http-nio-8080-exec-3] INFO p.c.d.a.controller.DataController [] – REST Communication – Time=407.306ms, Size=311bytes, Attributes=5, ArraySize=5
app-one_1 | 2025-05-28 17:10:23 [http-nio-8080-exec-19] INFO p.c.d.a.controller.DataController [] – REST Communication – Time=410.143ms, Size=301bytes, Attributes=5, ArraySize=5
app-one_1 | 2025-05-28 17:12:48 [http-nio-8080-exec-6] INFO p.c.d.a.controller.DataController [] – gRPC Communication – Time=848.870ms, Size=397bytes, Attributes=5, ArraySize=5
app-one_1 | 2025-05-28 17:12:48 [http-nio-8080-exec-11] INFO p.c.d.a.controller.DataController [] – gRPC Communication – Time=837.657ms, Size=413bytes, Attributes=5, ArraySize=5Upon reviewing the logs, noticeable fluctuations in response times were observed. Unlike the previous test, the times did not increase gradually. Using Matplotlib, NumPy, and SciPy, a set of calculations and visualizations were produced to further analyze this behavior, as shown in the graphs below.
The results show that the average (mean) response time for REST is higher than that of gRPC. REST has a mean response time of 254.23 ms with a standard deviation of 74.80 ms, indicating moderate variability and relatively consistent performance. In contrast, gRPC has a lower mean response time of 221.92 ms but a higher standard deviation of 206.80 ms, reflecting greater variability and less predictable performance.
To determine whether the difference in mean response times is statistically significant, a t-test was performed. The t-statistic value was 2.07, indicating a moderate difference between the two means. The resulting p-value was 0.0389, which is below the commonly used significance threshold of 0.05. Therefore, it can be concluded that the difference in response times between REST and gRPC is statistically significant.
Additionally, a box plot was created to visualize the distribution of response times for REST and gRPC. This chart highlights the differences in spread, median, and potential outliers between the two protocols, providing a clear comparison of their performance variability.
The box plot reveals that gRPC exhibits more outliers, particularly on the higher end (above 800 ms), suggesting occasional latency spikes.
Conclusion
Ultimately, both REST and gRPC have their pros and cons. Choosing the right architecture depends on the specific requirements of the application of what you’re building. This experiment was conducted to illustrate how response time in REST and gRPC varies with payload size and under concurrent load conditions.
All the source code used in this experiment including the client and server implementations, as well as the Python scripts for visualization and log analysis can be found in the following GitHub repository:
https://github.com/infazr/REST-vs-GRPC
If you’d like us to explore other architectural benchmarks or API strategies, feel free to reach out. We’re always up for a deep dive.
