Externalized component and communication approach - REST or RPC?

Question

This is a hypothetical scenario with some concrete parts.

Say that I have built a system that allows users to interactively arrange living room layout. The result of this arrangement is presented to user in a form of a RENDERED preview image.

The system is built using best practices, SOLID principles, and taking the Uncle Bob's Clean Architecture as one main of the guidelines - one of the reasons - to be prepared for the scaling.

The system is deployed as a web application monolith on the company's web server. After a while, due to a high load, I realize that RENDER component is a bottleneck and it is using a lot of system resources and needs to scale somehow.

The decision is made to move the rendering operation to the external service (different server, cloud, or something)

The existing components that are using render feature need to communicate with external render service somehow. Render service accepts the living room layout model as an input and provides output in form of the raster image, nothing needs to be mutated, persisted, no anything like this - just a simple function that accepts input and produces output.

Now, everybody are screaming REST and I also like some of the generalizations employed in there, but I don't see the REST like approach in here - It just does not align to the resources in any way, just seems to me like a wrong fit.

In other way, it appears to me that communication totally aligns with the RPC (over http of course) style.

So, which approach should I take on this scenario, REST or RPC?

If REST, how that should be realized in a detail?

Answer 1

So, which approach should I take on this scenario, REST or RPC?

"It depends." I'm sure you are shocked.

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction. Roy Fielding

REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them. Roy Fielding.

The first thing that leaps out at me is the question: multiple organizations. You aren't trying to create some world wide standard protocol for offloading living room rendering onto a server. This changes the calculus for long term compatibility quite a bit.

The second thought is caching; HTTP has really good caching support. If your use cases have significant re-use of rendered images, then having the caching done for you could be a good win.

So if the number of combinations is small (a billion? 10 billion?), and especially if a small set of them tend to be interesting at any given time, then caching might well pay off.

If REST, how that should be realized in a detail?

Well, it probably looks like a web form that allows the client to specify the living room layout model.

If the information fits into a query string, great! the calculation of the URI occurs on the client, which can then check to see if it already has a valid copy in the cache.

If the information doesn't fit into a query string, then you are probably looking at a POST to the server, which can calculate the URI and send it back to the client, and then protocol looks the same from there.

Answer 2

RPC over HTTP and REST will have similar performance since both will have to send the parameters and receive the result using the same protocol. The only difference could be caused by the encoding, but you could opt for JSON in both cases.

So the main criteria for choice is the API philosophy which best fits to your use case:

• The RPC API philosophy is to provide services that correspond to methods, e.g. renderLayout(). There is a natural fit with your use case, since you just want to distribute existing methods of your current processing across several nodes. But on the other side, there are quite a few variants of RPC around there, so you'll create some interoperability constraints.

• The REST API philosophy is resource oriented and uses a well known uniform interface. The endpoint would in principle be named according to a resource and a unique ID, e.g. /rendered-layout/2567. So you could create a rendering with a POST (parameters in the body), and later reuse this rendering with a GET for the same ID, and get the whole thing accelerated thanks to caching. The resource oriented paradigm would require a change in your design. On the other side, the benefit is that it decouples more the components and reduce interoperability constraints since REST is quite universal.