RPC with JSON, why does everyone hype REST so much?

Question

If I have a browser handling PHP application, a mobile backend in PHP and an API for the 2 of them, consider the request to log in.

In REST, all this logic would have to be duplicated in controllers in the browser PHP app and the mobile backend.

Not only would it be duplicated, the amount of calls needed is so much more than RPC.

REST. 
Call 1 : Fetch user object by email address.
Call 2 : Fetch password by userId.
Call 3 : (If correct password) Change the last login time on user and save user.

That would all be done with one request in RPC. Loads of other examples where it takes 1 RPC call but takes 3+ REST api calls, not to mention duplicates code horribly across applications that have different authentication. The mobile backend uses OAuth and the browser uses PHP sessions.

I don't get why everyone hypes REST so much, it was the initial way I was taught to program, but then I started another job where they use RPC and it works so much better.

My question clearly puts forward different arguments and shows a different form of architecture. Don't just auto flag as a duplicate.

Answer 1

I'd comment rather than answer, but I don't yet have the reputation.

What kind of RPC are you talking about? REST (over HTTP) may be more robust, in that firewalls and web proxies will allow it to pass, while RPC using a different protocol and/or non-HTTP ports may be blocked.

Sounds like strict adherence to the principles of REST is making your hypothetical REST API more complex than it needs to be. Must you remain highly "RESTful", or can you combine the three operations into one "method"? Or, can you change/extend the model in your server to allow one request to accomplish all three and yet remain RESTful? For example, PUT the last login time of the user, but require the login credentials to accompany the request, and fail the request if they are incorrect for the user. I admit, this is unintuitive, but maybe you can think of something better.

I hope you're not storing passwords in the clear, nor storing them such that they can be converted back to cleartext for purposes of comparing them.

Answer 2

As Alexandru Marculescu has pointed out, the response to your question is buried somewhere in this flame war. By "hype" I think you are referring to how REST seems to be the silver bullet to connect machines in the web. I believe this sentiment, is the result of REST being an architectural style without a standard (not even a de facto one) that is therefore applied and interpreted differently by their users.

Representation State Transition (REST) is indeed designed with web applications in mind, so far as making tacit assumptions about HTTP being the underlying protocol. REST aims to achieve several non-functional requirements (such as simplicity) by adding constraints.

Strict adherence to REST requires following HATEOAS principle (Hypermedia as the engine of application state), which is rarely done. This is the fundamental constraint that allows client and server to be decoupled, and therefore be more maintainable in the long run (more on Wikipedia).

The main drawback of these self-imposed limitations are short-term efficiency (as you have experienced) and an overall higher architectural complexity.

In conclusion, I believe the hype comes from a widespread misunderstanding of what a truly RESTful architecture would entail and a lack of distinction of what an HTTP endpoint vs REST API.

I'd rather not go over your example, as we would risk of digressing in a discussion about authentication schemes. I will point out that it's not bad to support multiple authentication schemes, and it could easily be desirable (i.e., social networks).