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