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