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