I'm sure the title sparked a healthy reaction — 'Here we go again...'. But allow me to take your attention for 5-10 minutes, and I'll try not to disappoint your expectations.
The structure of the article will be as follows: a stereotypical statement is taken, and the 'nature' of the emergence of this stereotype is revealed. I hope this will give you a new perspective on the choice of data exchange paradigms in your projects.
To clarify what RPC is, I suggest looking at the standard . With REST, there is no clarity. And there shouldn't be. All you need to know about REST is that it is indistinguishable from .
RPC requests are faster and more efficient because they allow for batch requests.
The point is that in RPC, you can call several procedures in a single request. For example, create a user, add an avatar, and subscribe them to some topics, all in one request. Just one request, yet so much benefit!
Indeed, if you have just one backend node, it may seem faster with batch requests. Because three REST requests will require three times more resources from a single node to establish connections.
Note that the first request in the case of REST must return the user ID, in order to perform subsequent requests. This also negatively impacts the overall result.
However, such infrastructures are found mostly in in-house solutions and Enterprises. At most, in small WEB projects. But full-scale WEB solutions, especially those labeled HighLoad, should not be constructed that way. Their infrastructure must meet high availability and load criteria. And the picture changes.
The active channels of the infrastructure are marked in green in the same scenario. Notice how RPC behaves now. The request uses the infrastructure only from one side from the load balancer to the backend. Meanwhile, REST still loses in the first request, but catches up using the entire infrastructure.
Simply introduce not two enrichment requests into the scenario, but say five or ten… and the answer to the question 'who wins now?' becomes less obvious.
I suggest we take a broader look at the problem. The diagram shows how infrastructure channels are used, but infrastructure is not limited to channels. An important component of a high-load infrastructure is caching. Now, let's obtain some user artifacts. Several times. Let's say 32 times.
Notice how noticeably the infrastructure for RPC has 'improved' to meet high load requirements. The fact is, REST harnesses the full power of the HTTP protocol, unlike RPC. In the diagram presented, this power is realized through the request method — GET.
HTTP methods have, among other things, caching strategies. You can learn about them in the documentation at . RPC uses POST requests, which are not considered idempotent, meaning that repeated submissions of the same POST requests can yield different results (for example, each time a comment is submitted, a new copy of that comment appears) ().
Therefore, RPC fails to efficiently utilize infrastructural caches. This results in the need to implement software caches. Redis is depicted in the diagram in this role. A software cache, in turn, requires an additional coding layer from the developer and significant changes to the architecture.
Now, let's calculate how many requests REST and RPC generated in the considered infrastructure.
Requests
Incoming
to the backend
to the DBMS
to the software cache (Redis)
TOTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] at best (if a local cache is used) 1 request (one!), at worst 32 incoming requests.
In comparison to the first diagram, the difference is striking. It now becomes clear the advantage of REST. However, I propose not to stop here. An advanced infrastructure includes CDN. Often, it also addresses the issue of countering DDoS and DoS attacks. Let's get:
For RPC, things get very bleak. RPC simply cannot delegate work with CDN load. We can only hope for attack countermeasures.
Can this be the end? Again, no. HTTP methods, as mentioned above, have their own 'magic'. There's a reason the GET method is widely used on the Internet. Note that this method can access part of the content, can set conditions that can be interpreted by infrastructural elements even before control is handed over to your code, and so on. All this allows for the creation of flexible, manageable infrastructures capable of processing truly large streams of requests. In RPC, this method... is ignored.
So why does the myth that batch requests (RPC) are faster persist? It seems to me that most projects simply do not reach a level of maturity where REST can showcase its strengths. Moreover, in smaller projects, it is more likely to reveal its weaknesses.
Choosing between REST and RPC is not a personal decision made by an individual in a project. This choice should meet the project's requirements. If the project can extract everything that REST truly offers and it is genuinely needed, then REST will be an excellent choice.
But if to gain all the benefits of REST, you need to hire DevOps for agile infrastructure scaling, admins for managing the infrastructure, and an architect for designing all layers of the web service... while the project sells three packs of margarine a day... I would lean towards RPC, as this protocol is more utilitarian. It does not require deep knowledge of cache operations and infrastructure, but instead focuses the developer on simple and clear calls to the procedures they need. The business will be satisfied.
RPC requests are more reliable because they can perform batch requests within a single transaction.
This characteristic of RPC is undoubtedly a plus, as it makes it easy to keep the database in a consistent state. However, with REST, things become more complex. Requests can arrive inconsistently at different backend nodes.
This 'disadvantage' of REST is the flip side of its advantage described above — the ability to efficiently utilize all resources of the infrastructure. If the infrastructure is poorly designed, especially if the project architecture and the database in particular are poorly designed, then this can indeed be a significant pain point.
But are batch requests as reliable as they seem? Let's consider a case: we create a user, enrich their profile with some description, and send them an SMS with a secret to complete registration. That is, three calls in one batch request.
Let's look at the diagram. It shows the infrastructure with high availability components. There are two independent communication channels with SMS gateways. But… what do we see? When sending the SMS, a 503 error occurs — the service is temporarily unavailable. Since the SMS sending is packed in a batch request, the entire request has to roll back. Actions in the database are canceled. The client receives an error.
The next attempt is a lottery. Either the request hits the same node again and returns an error again, or we get lucky, and it succeeds. But the main point is that at least once our infrastructure has already worked in vain. There was a load, but no profit.
Alright, let's imagine that we made an effort (!) and thought through a scenario where the request can be partially successful. The remainder, we will attempt to execute again after some interval (What interval? The frontend decides?). But the lottery remains. The SMS sending request has a 50/50 chance of failing again.
Agree, from the client's perspective, the service does not seem as reliable as one would hope… and what about REST?
REST again uses the 'magic' of HTTP, but now with response codes. In the case of a 503 error at the SMS gateway, the backend translates this error to the load balancer. The load balancer, upon receiving this error and not breaking the connection with the client, directs the request to another node, which successfully processes the request. That is, the client receives the expected result, and the infrastructure confirms its high status as 'highly available'. The user is happy.
And again, that's not all. The load balancer did not just receive a 503 response code. This code, when responded to, should ideally be accompanied by a 'Retry-After' header according to the standard. The header lets the load balancer know that it should not disturb this node for this route for a specified time. Subsequent SMS sending requests will be directed immediately to a node that has no issues with the SMS gateway.
As we can see, the reliability of JSON-RPC is overestimated. Indeed, it is easier to organize consistency in the database. But, in that case, the reliability of the system as a whole will suffer.
The output is largely analogous to the previous one. When the infrastructure is simple, the clarity of JSON-RPC is undoubtedly its advantage. If the project requires high availability with heavy load, REST seems like a more correct, albeit more complicated solution.
The entry barrier for REST is lower.
I believe the above analysis, which debunks established stereotypes about RPC, clearly shows that the entry barrier for REST is undoubtedly higher than for RPC. This is related to the need for a deep understanding of how HTTP works, as well as the necessity to have sufficient knowledge about existing infrastructural elements that can and should be applied in WEB projects.
So why do many think that REST will be simpler? Personally, I believe this apparent simplicity stems from the REST manifest itself. That is, REST is not a protocol, but a concept… REST has no standard, only some recommendations… REST is not more difficult than HTTP. The apparent freedom and anarchy attract 'free-spirited' developers.
Undoubtedly, REST is not more difficult than HTTP. But HTTP itself is a well-thought-out protocol that has proven its worth for decades. If there is no deep understanding of HTTP itself, one cannot judge REST.
However, one can judge RPC. It is enough to take its specification. So do you need ? Или все же хитрый REST? Решать вам.
I sincerely hope I have not wasted your time.
Source: habr.com
