What protocol for my API?
When building an application or almost any piece of software, you will have to face the question what protocol should I use for my API?
Let’s explore our options.
1 — REST
Historically the most comonly ised, it is made for web browsers to access data from servers. Still the best for this use case.
It works over http, using JSON payloads.
Strict structure for requests & responses. Making it predictable but less flexible: a change to the API is a rework on both client and server side.
It is best suited for retrieving data, in a structured and predictable way.
2 — GraphQL
As APIs got more common, we needed to access data more efficiently.
GraphQL came to life. Solving the two biggest problems with REST:
- It returns ALL the data, even what you don’t need
- It is lengthy to create (many endpoints, verbs, parameters)
With GraphQL, you have only one endpoint — and the user only gets the data that is requested.
What are RPC APIs?
Remote Procedure Call.
A function can be called within an application. Classic. You give parameters and get a result.
Now, how about you call that same function, but from outside of the application? Like from a different service or even a different computer?
That’s RPC.
Get Carnus Clement’s stories in your inbox
Join Medium for free to get updates from this writer.
These APIs are meant to call the execution of function rather than retrieving data like REST and GraphQL.
3 — JSON-RPC
This is becoming more popular as it is the standard protocol for MCP servers.
Request
{
"jsonrpc": "2.0",
"method": "getNameUser",
"params": {
"id": 23
},
"id": 1
}Response
{
"jsonrpc": "2.0",
"result": {
"id": 23,
"name": "Thomas"
},
"id": 1
}Notification
{
"jsonrpc": "2.0",
"method": "update",
"params": [1, 2]
}It uses JSON payload with only 4 fields: jsonrpc, method, params and id.
If no id is sent, this is a notification. It won’t get a response.
Payload is a convention, not a configuration. Meaning you don’t need to change the configuration of your message when something changes on the backend.
The way to pass arguments is made simple and it uses only one endpoint.
More flexible with less setup time but less predictive.
4 — gRPC
Another protocol for executing functions across microservices or computer networks. Developed by Google.
✅ Faster than JSON-RPC (because it uses binary and not text)
❌ Harder to troubleshoot and understand (for the same reason as above)
- More strict structure then JSON-RPC






