Hacker News Reader

Comment by marklgr | Hacker News Reader

I happen to have worked with the system author coded/maintained. We're not in touch and I'm not here to defend him, but he's no hipster. Rather, he had to integrate a lot of heterogeneous services, as that system was acting like a hub between many departments in the company, with various tech skills and resources. If anything, I suspect he's more kind of unsatisfied by changes that he deemed unnecessary.

As a note aside, the xmlrpc endpoints of the aforementioned system worked fine and saved us time.

View on HN

Xmlrpc is incredibly underappreciated.

Xmlrpc is simple and it works.

Xmlrpc is soap without the bullshit.

I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps

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.

btw SOAP was supposed to be "xmprpc standardized"

I remember well the meeting when things started to go off track...

Im actually curious now that you mention it but don’t expand on it. Was the road to hell really paved with good intentions?

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

I agree.

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

https://www.youtube.com/watch?v=cEyVfiix1Lw

Reply on news.ycombinator.com