REST is the new SOAP

While on the surface that might seem like a workable idea, getting input validation right is going to require more syntax (making it far less clean). Specifically, URLs are only ever string data, so without type annotation everything is strings, even if it looks like a number, array, or even more complex data type.

“Real illuminated REST”? The REST spec?

It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles.

Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a CORBA equivalent and then almost succeeded with SOAP/WS-*. People got strident to fight the dollars that were lined up. It’s easy to forget there was no powerful web/internet community with social media and blogging platforms in those days, it was all mailing lists and a couple of conferences vs. Marketing budgets, sales teams, and agenda-wielding engineers on standards bodies from Microsoft, IBM, BEA, Sun, HP, etc.

All RESTful means is that something is attempting to conform to the style. There never was a spec.

> are used to dealing with wrappers written for their language anyway

And the wide availability of those is because it's so easy to build one over obvious REST apis.

Those who refuse to learn history are doomed to repeat it.

REST is not the end of history, there can and should be successor architectures, but RPC is not that successor. It’s been around a very long time and fell out of fashion for good reason. It is a convenient approach that can be used if you have major control over all the interfaces, endpoint implementations and underlying infrastructure, as Google does for its use of gRPC. It really falls over if you want independent implementations and variable infrastructures over a large scale, as is the case for most Internet / Web interactions.

RPC is fundamentally flawed in that it tries to pretend that the network doesn’t exist and that distributed systems don’t have fundamentally different concerns than single computer systems. A good overview of this history from 2009 is here: https://www.scribd.com/mobile/document/24415682/RPC-and-its-...

Keep in mind that REST only became popular around 2007, it was an uphill battle to popularize it from 2001 onwards. The web had grown to a mammoth, and vendors couldn’t make money off it, so wanted to replace it with CORBA or some other RPC (SOAP). It took a concerted effort to fight that in standards bodies, on mailing lists, on blogs. Those days didn’t have Github or social media or a myriad programmer conferences. The posts are still up if you want to see them. This history of having to fight to be perceived as relevant and useful is why REST tends to have a bit of misguided religion behind it. SQL proponents had the same issue longer ago.

The Web and REST led to the largest increase in networked computer interoperability in history, after the TCP/IP suite and Telnet. The architectural style is what catalyze JavaScript into such a ubiquitous language as it made mobile code a first class citizen in the architecture. It’s what catazlyed Google into a powerhouse as it baked self describing, uniform interfaces as the standard, enabling spidering, indexing and analytics on a global scale. Moving on from it will be harder than people realize.

By all means, be an engineer - use RPC if it fits your problem and constraints better. Use event streams if it fits your problem better. Use GraphQL or SPARQL if a data query interface is a better solution for your needs. There is no one architecture. But please, rants about how the world would be better if we all did RPC, it comes across as very divorced from the wide variety of problems and suitable architectures out there.

Although the article somewhat exaggerates the problem and in fact REST is great for many applications, truth is (IMHO) REST is indeed overrated and the RPC style (don't confuse it with SOAP!) is over-vilified in the IT culture. In so many (though far not in all of them) cases a concise JSON-RPC API would be a much more elegant solution than REST. I believe this is a great example of where the "right tool for the job" principle should be applied rather than a buzzword cult.

Many comments here emphasize on the problem of developers expecting RPC functions to be as reliable as local functions are. Well, that's their own problem, IMHO. The only appropriate solution is to remind them they are doing it wrong, e.g. the same way REST gurus use to remind everybody they are doing REST wrong. In fact there is a huge number of "developers" around who just invoke all the file system, database and network (REST, RPC, SOAP or whatever) calls synchronously, don't validate inputs nor outputs and don't even wrap the calls in try/catch (believe me, I used to support a fairly popular API and had to explain this stuff to just soooo many people complaining about their apps hanging or panicking on occasions when our REST API quirks (e.g. a field is missing from the response) or fails).