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?