Having implemented many web service APIs in both SOAP and REST I have the same opinion.
XMLRPC or JSONRPC seem to be the happy middle ground.
The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny.
I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.
But you can with REST. Most of this conversation is a strawman against REST. Creating or changing resources can impact other resources. It's obvious / logical. Responses can include the things that they impacted along the way. Much of this thread amounts to "I used this shitty REST API once" or similar for RPC.
Well, it depends on how you reckon REST. I can assure you the real world issues I've run into don't have anything to do with the frameworks used. The impedance mismatch between what one would consider a sane API that could just as easily be implemented as a compiled library and the mappings of that API to HTTP verbs and what is considered proper REST were where the problems were.
My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
I don’t really remember SOAP since that was over a decade ago, but what I like about REST is that it harmonizes the front end and backend structures of the application and it makes things predictable. It also puts up some guardrails against obviously dumb behaviour like deleting records via a GET and with JSON API, makes it possible for things to snap together once you’ve got the structure right. Ember Data + Rails set up to follow JSON API is just unbelievably productive. Pagination, filtering, optionally including other resources, linking (both to the related resource itself and to the relationship itself) it’s really fast, consistent, powerful, flexible, and secure. It’s not always performant, but when performance is important I make one little RCP or nonstandard REST endpoint (say return a link to a big TSV blob) and I move on with life.
It lacks conventions thoug so every api is more quirky and even sloppier than a bad REST api. At least with REST there’s some existing structure and it’s not completely up to the imagination of someone in a hurry.
I don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".
If you control client and server and the server's functionality will for the foreseeable future is limited in scope, xmlrpc is the boss.
We had a django/rest based internal microservice. Was a pain to build and maintain. Switched to xmlprc (it's in Python stdlib), removed tons intermediary code, and wrote only a few bits of new code.
This talk by Jonas Neubert opened my eyes to how xmlrpc can be the glue for Python (which is already glue).
