5 ms·
I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC wer
by mpdehaan2 11y ago
I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC were things. SOAP was never good anyway, deeply buried in standards committee goo. But there are still things I miss from these things. When I found XMLRPC after doing all these things, it was very much a "WOW" moment. (JSON of course, with it's definite differences between maps/hash-tables and lists, is greatly superior to me).
A generic problem with REST APIs is they all handle collections, associating items with subcollections (including establishing and removing 1-to-many or many-to-many relationships between existing objects), query strings, authentication, and pagination very very differently.
Not all APIs are discoverable either, many don't do structured error codes. Thus to talk to one, rather than just using client-library, more work has to be done, often repeated work in multiple languages. Lots of REST APIs aren't well discoverable and rely on special logic to form up URLs, and many have weird verb pollutions - modelling a long running job for instance, I've typically have done as posting a job descriptor to a job collection, because the standard verbs don't really apply.
All being said, I prefer a nice broweseable REST API, but despite the accursed "XML" in the name, XMLRPC was easy - there were bindings in multiple languages and it was easy to ask an API what methods were supported. Problems came in the undefined parts - like whether "None" could be passed, and so on.
I can design and build some very elegant REST APIs, but the clients DO have work to do, every time. A good example for me was trying to write to GitHub's API, and then being angry at the way pagination was overcomplicated and URLs were not discoverable. (It might have gotten better).
BTW, if you are doing Python and want a GREAT foundation in pagination, discoverability, and so on, I recommend Django REST framework. One catch is you may wish to extend some of the serializers to return URLs relative to other URLs.
I don't think RPC is evil so much - over HTTPS and backed by a good webserver, and done so that it's stateless (something a pre-forking webserver (esp with MaxRequestsPerChild in play in Apache) forces you into, not so much REST protocols all by itself), I think it's just not socially acceptable.
So statelessness good, having to write client-specific "flavors" of REST, well, it's just reality.
(In other news, I'm disappointed all my He-Man figures got sold in the 80s so I can't illustrate tech cartoons with them, well done)
- smacktoward 11y ago> SOAP was never good anyway, deeply buried in standards committee goo. IMO SOAP in its very early days was actually fairly pleasant, at least when compared to the existing alternatives (things like COM and CORBA, which, ew). XML-RPC was also nice, in a "keep it simple, stupid" kind of way. Then of course SOAP crushed XML-RPC, the crew of the USS Enterprise got their hands on it, and the rest is (depressing) history.
- marcosdumay 11y agoI've met SOAP when IBM was already pushing it, thus I may have completely missed the early days. But I never even imagined I'd hear somebody say SOAP was more pleasant than CORBA. Yes, working with is CORBA barely better than hitting your foot several times with a hammer, but relative to SOAP, it's a breeze. Anyway, it's kind of depressing that even now the best RPC we have to show is REST. It's a problem that looks so simple from a distance, why can't somebody build something really great here?
- RangerScience 11y agoYar, in my limited experience with SOAP, it's like Java: Good ideas under the hood, but then the usage you usually see is just /terrible/.... But I really like the idea that the API can tell you about the API, and do kind of wish JSON REST APIs had similar patterns. I think the main problem that XML runs into is that it's used a data interchange format and/or a data serialization, instead of a markup. I think the bit you're missing from the XML APIs - that makes you re-implement things - is the lack of an API descriptive document (like the WSDL). If that was a thing, REST is at least as automatically ported as any XML API style. (Someone would still have to write the libraries that turn the document into objects/functions, but that happens with the XML stuff as well)