[sopooneo]

I'm sort of with you, though I've read quite a bit at this point and interacted with a number of APIs of varying degrees of "RESTfulness".

The biggest question I wish the various tutorials would address is: why is REST a good idea? Why is this particular way of doing things better than others?

And here's one thing I believe is true, that I have literally never seen in a REST tutorial: sometimes REST is not the best way to go. Sometimes an RPC architecture is better.

[BerislavLopac]

"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.

[SilasX]

>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?

[BerislavLopac]

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.

[SilasX]

Definitely. Just pass that memo along to the "apps should work purely through REST API calls" crowd.