HTTP API response size matters

Sumeet More
3 min readDec 4, 2022

--

Pic credit: https://unsplash.com/photos/tTfDMaRq-FE?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink

Disclaimer: This article is based on my current knowledge and understanding. If you have any query or see any improvement, please mention in the comment section

Recently I was travelling to an international destination. First thing which I did was to recharge my local cellphone number with an international roaming pack. However I noticed that it had limited data pack due to which I had to use mobile data carefully. As a software engineer , I immediately realised that due to the limited data pack, APIs should be efficiently designed to deliver more information with less data consumption

To understand why http api response size matters, let’s take an example and implement it with different approaches

Example : Build an api which brings 1000 records

Approach 1 : REST API ( JSON output)

output :

api response size:

api response size with this approach is 40.95KB

Approach 2: GRPC API ( protobuf based)

output:

api response size :

Based on the above two images, api response size with this approach is 11780 bytes + 5 bytes = 11.785 KB

Based on both approaches, we can see grpc approach api represented the same 1000 records in smaller response size. Hence if you are an international traveller with international roaming pack, you will always prefer apps/ web apps using grpc/protobuf based api since it will efficiently bring data without exhausting data pack.

The reason why approach 2 is performing well compared to approach 1 w.r.t api response size :

Approach 1 api was designed using json and http 1.1
Approach 2 api was designed using protobuf and grpc(http2)

~ Happy coding

References:

  • https://www.reddit.com/r/grpc/comments/w6pl55/comment/ihk0anl/

--

--

Sumeet More
Sumeet More

Written by Sumeet More

Software Engineer 2 at Microsoft | Backend Engineer and Architect| Blockchain & ML enthusiast | C#,.NET Core, Rust, Javascript and Go

Responses (1)