"sometimes REST is not the best way to go. Sometimes an RPC architecture is better."
I think that the full versions of there acronyms make a pretty good job of explaining what is best when.
"REpresentational State Transfer": obviously, it transfers state, i.e. information about a certain resource at a given moment. "Remote Procedure Call": obviously, it calls a procedure, which may involve several state changes and other activities. Of course, a procedure may be masked behind a REST endpoint (e.g. when you POST some data and do some procedure before you end up with a certain state) and vice versa (e.g. a simple getter), but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures.
>but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures.
Indeed, but that just raises the question: what would possess you to write an app out of SQL calls rather than general functions? So then why do the Web equivalent thereof?
You don't, of course. What you do is build an app which is using REST to store data somewhere online, and the app itself may be in the user's browser, on a mobile phone or anywhere else for that matter.
I think that the full versions of there acronyms make a pretty good job of explaining what is best when.
"REpresentational State Transfer": obviously, it transfers state, i.e. information about a certain resource at a given moment. "Remote Procedure Call": obviously, it calls a procedure, which may involve several state changes and other activities. Of course, a procedure may be masked behind a REST endpoint (e.g. when you POST some data and do some procedure before you end up with a certain state) and vice versa (e.g. a simple getter), but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures.