Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

Aah xml-rpc; don't know why it is found interesting these days but still ..,

My thinking is: if you employ a relative high-ceremony meta-language such as XML as service payload format, then you'll at least want to use its features to model free yet strictly validated information exchanges (such as ASN-based protocols have been doing). But xml-rpc doesn't give you that and imposes param=values logic known from simple URL-encoded invocation forms instead, improving little over those.

Then SOAP was introduced as the big unified payload serialization format covering document- and RPC-oriented uses. We all know just how it sucked.

But then came the even worse end result/eternal September of "REST" APIs - a misuse of HTTP and blatant and painful misappropriation of Fielding's concepts, whose proponents used SOAP's flaws as an excuse for their anti-engineering practices.

View on HN

If REST APIs are the worst, how does that account for their immense utility and popularity?

I wrangled XML-RPC and SOAP back in the day. It was bad enough when you had exactly the same stacks talking to each other. When you had to interop between systems, ie .NET talking to Java, which was half the point of it all, it was a whole new circle of hell.

Trying to get Python SOAP stacks to talk to Java/.NET banking services was another thing too.

I still get mild PTSD from thinking about XMLsec and XML c14n.

I have to disagree.

I used XML-RPC exactly twice, but it proved to be a quick solution to nasty integration problems and we were very happy with it.

Case #1 - we had to implement an interface to book flights on Amadeus (https://amadeus.com/en). In order to guarantee the caller identity they provided a C library (binaries that you had to link with your stuff) that would generate tokens that you would then add to your own calls to them to guarantee your identity. We were trying to use it from a Solaris machine, and the library would bomb at each call. But their Windows binary module worked fine, so we basically put up an XML-RPC connection between our Solaris hosted main app and a little Windows service which would simply provide the token for us to embed in the subsequent call. (This was the only way we could find to hit our release date in time, and it worked fine for 5 years serving hundred of thousands of calls every year).

Case #2 - less "business critical", but still fine: I was on sick leave from the office recovering from minor trauma to my knee and here is what I suggested to a guy trying to use a PERL library as part of non-PERL stack: https://stackoverflow.com/a/2635719/54504

(it was part of his final exam for a degree in CS, I provided more assistance outside of StackOverflow and he was very happy with the results).

Yes SOAP interoperability sucked, no arguing about that. The fact alone that you needed interoperability guidelines (WS-I) on top speaks volumes about W3C's derailed standardization effort - a similar problem is hunting today's OAuth standard btw.

But just that SOAP sucks doesn't mean "REST" is ideal. Fallacy of the excluded middle and all.

REST was at least spiritually trying to adhere to the ideas of HTTP verbs.

It not being a rigid protocol was a boon for web development although it generally meant "REST" was so nebulous people would describe their usage as "REST-like" or "REST-ish" if they broke conventions (like just using POST for most payloads)

But I'd say most of all it took off because it was simple and people like simple, particularly after jumping through hoops for a decade prior.

> REST was at least spiritually trying to adhere to the ideas of HTTP verbs

That's kindof the problem:

Except in the case where a thin browser front end is rendering a single response payload transferred by necessity over HTTP a la XSLT (which we're not doing anymore for better or worse) there's absolutely no rational reason to stick to "REST principles" in quasi-religious manner and exegetic interpretation of Fielding's thesis that coined that term. In fact, I'd say it's counterproductive, because a simplistic "REST" facade doesn't even begin to describe the actual interaction between backends or rich frontends and backends, those interactions often being stateful and much more involved and granular than sending back-end-forth idealized full "representations" or flawed over-exposing ideas of the nature of a backend concept. You might think that SOAP-like UpdateOrderLineItemBilling granular ops suck, but these are much more representative and telling than coarse pretentious REST APIs suggesting you could update anything at any point in time during the course of a process, when in reality backend logic just doesn't work that way (eg in the ecommerce example, you'll have to honor the delivery and billing status of items to cancel, and compensate or retour items accordingly, etc).

Really, "spiritual programming" isn't an engineering discipline; you can model your backend-to-backend interactions freely without having to appeal to concepts from HTTP taken completely out of context.

> My thinking is: if you employ a relative high-ceremony meta-language such as XML as service payload format, then you'll at least want to use its features to model free yet strictly validated information exchanges

No? There is no relationship between the two. XMLRPC is a straightforward application of XML, its intended niche was similar to JSON(RPC): point the client at an endpoint and go to town.

And if you were using Ruby or Python it worked nicely, and still does really.

Well what you seem to be arguing more about the misrepresentation than the final product.

Given the alternatives it really seemed like a lesser of the three/four evils.

Reply on news.ycombinator.com