Questo è uno scenario ipotetico con alcune parti concrete.
Dire che ho costruito un sistema che consente agli utenti di organizzare in modo interattivo il layout del salotto. Il risultato di questa disposizione è presentato all'utente sotto forma di immagine di anteprima RENDERED.
Il sistema è costruito utilizzando le best practice, i principi SOLID e prendendo l'Uncle Bob's Clean Architecture come una delle principali linee guida - una delle ragioni - per essere preparato per il ridimensionamento.
Il sistema viene distribuito come un monolito di applicazioni Web sul server Web dell'azienda. Dopo un po ', a causa di un carico elevato, mi rendo conto che il componente RENDER è un collo di bottiglia e utilizza molte risorse di sistema e deve ridimensionare in qualche modo.
Viene presa la decisione di spostare l'operazione di rendering sul servizio esterno (server, cloud o altro)
I componenti esistenti che utilizzano la funzione di rendering devono comunicare in qualche modo con il servizio di rendering esterno. Il servizio Render accetta il modello di layout del soggiorno come input e fornisce output sotto forma di immagine raster, nulla deve essere mutato, persistente, niente di simile a questo - solo una semplice funzione che accetta input e produce output.
Ora, tutti stanno urlando REST e mi piacciono anche alcune delle generalizzazioni impiegate, ma non vedo l'approccio REST come qui - Semplicemente non si allinea alle risorse in alcun modo, solo a me sembra come una misura sbagliata.
In un altro modo, mi sembra che la comunicazione sia totalmente in linea con lo stile RPC (over http ovviamente).
Quindi, quale approccio dovrei adottare in questo scenario, REST o RPC?
Se REST, come dovrebbe essere realizzato in un dettaglio?