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.
