[dozzie]

> [...] fine, go ahead and do your RPC. Just don't try to tell me that it's anything other than RPC, with all the problems and warts we all know.

Why the heck do you think that "lol, you use RPC" would be an insult? Because you clearly send this message with your tone.

I put RPC wherever I need an operation(s) to be called remotely. And yes, I do use dedicated RPC protocols (namely, XML-RPC, for popularity of its clients). I rarely create things that boil down to being a CRUD database interface, so I find REST very limiting.

> From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead.

Apparently you haven't worked with SOAP. No, it's not respectable. It's overcomplicated itself, it uses overcomplicated format (XML with namespaces), and its tooling is overcomplicated, too (e.g. try to control how WSDL looks like, so you can swap implementation languages; or try to create WSDL beforehand, and then implement its backend in a language of your choice).

Really, in HTTP-based remote call protocols (this includes REST!), Microsoft hit the spot twenty years ago with XML-RPC. The only two things missing are null/None/undef encoding and named procedure arguments.

[toyg]

> Microsoft hit the spot twenty years ago with XML-RPC.

Well then, why are we even arguing about this? You like pasta, I like pizza, and never the twain shall meet. REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

If you like XML-RPC, by all means keep using it. I just don't see the point in advocating (as TFA does) that people should abandon working on REST implementations in order to embrace what is basically JSON-RPC, i.e. a completely different thing from a philosophical and design perspective.

(I've ignored the ad-hominems and bad guesses on my work history. Can we keep it civil?)

[dozzie]

> REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

Not quite. REST was born out of rejection for SOAP, not XML-RPC. It addressed following issues (after Paul Prescod's article, http://www.prescod.net/rest/rest_vs_soap_overview/):

* SOAP didn't address objects with URIs, so you couldn't integrate your services with RDF and semantic web; RDF and SemWeb didn't boot very well, so I wouldn't call it much of a problem today.

* SOAP development was driven by software vendors instead of academics. This point presumably implies that SOAP and WSDL were a bloated piles of crap (which SOAP and WSDL are indeed).

* Prescod stated that "mechanism, not policy" results in a more flexible design, which is funny, because REST is more a policy (architectural style), with SOAP being now a well-defined, if complex, mechanism.

And now tell me, which of these people are taking into consideration when they build their REST APIs? I would say none. Most often they simply cram several operations on several resources, serializing data to JSON and calling it a day.

[coldtea]

>REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

Not even remotely true. REST was a re-invention of XML-RPC wheel -- for the web and using baroque HTTP conventions that were meant for documents and hyperlinks.

XML-RPC was never rejected because it never caught much on in the first place. On the enterprise they pushed for SOAP at the same time, and on the web it wasn't yet a period were anybody really did rpc (plain AJAX, REST or any other kind).

In terms of simplicity it goes like: XML-RPC -> REST -> abyss -> SOAP, with XML-RPC and REST both on the far "simpler" end of the scale compared to SOAP.

[dragonwriter]

> Not even remotely true. REST was a re-invention of XML-RPC wheel -- for the web and using baroque HTTP conventions that were meant for documents and hyperlinks.

Not even remotely true. REST is an architectural style inspired by the then-existing web, describing an idealized structure based on it, and developed in parallel with and guiding HTTP/1.1. It does not mandate HTTP conventions, though HTTP is itself an example of the style.

REST only involves HTTP conventions to the extent that one decides to use it over HTTP, and only because HTTP involves (obviously) HTTP conventions.

[coldtea]

Not even remotely true.

REST is what it is in practice, not what some guy originally proposed as REST, in the same way modern words are not their etymology in Latin or Greek.

And in practice it's a re-invention of RPC, similar to XML-RPC, over HTTP and JSON, but with less rigor.

Kind of like any big C program has an ad-hoc implementation of half of Common Lisp thing.

>REST only involves HTTP conventions to the extent that one decides to use it over HTTP, and only because HTTP involves (obviously) HTTP conventions.

Ok, then you should have no issue with not using HTTP conventions and just use HTTP for transport.