The others, who came from the world of desktop applications and RPC-like binary communication protocols, just started climbing the learning curve of REST trying to incorporate its principles into their brand new web APIs as though it is a new standard.
REST is relatively old concept. It was first introduced back in distant 2000 by Roy Fielding in his doctoral dissertation. When it was presented it made a revolution. REST gave to often chaotic web APIs a well deserved structure. But REST wasn’t just a new architectural style it was the driving force of the new era of web APIs which are now almost everywhere.
Many people who design their APIs according to the principles of REST rightfully believe that REST is better then RPC due to its predictability and semantic and that API design which follows principles of REST is easy to understand and therefore to maintain.
Interestingly, the fact that HTTP based APIs are rapidly superseding all other kinds of APIs often leads to the feeling that REST was meant to replace RPC and so RESTful style is often considered as an opposition to RPC.
REST is all about distributed hypermedia systems and so it means HTTP. When HTTP is gluing layers written in different languages thinking about resources is perfectly justified. But as long as both sides can share a source code REST appears to be an abstraction standing in the way it is meant to be used – as an API which eventually turns to be a bunch of remote procedure calls (RPC) at both ends.
Given all of the above we will be soon in a situation where it becomes irrelevant which particular conventions are used when endpoints speak HTTP. Developers working on a system which consists of communicating tiers implemented in the same language are primarily concerned about API calls. How this calls are actually mapped to the underlying media and what concrete protocol is used become implementation details.
Is history really moving in circles and we are now back to RPC again?