I will bet money that most of these "RESTful" APIs are nothing of the sort. In almost all cases, when somebody says they're using REST, they're <i>actually</i> using ad-hoc XML-RPC -- fixed URLs, non-descriptive content, etc. Ignorant programmers have fixated on trivial aspects of some REST applications (use of PUT/DELETE, "pretty" URLs) and ignored all the important aspects.<p>This sort of thing happens a lot in software culture -- see people claiming Java or C# are object-oriented, that C++ is functional, that Python or LISP are "scripting languages". It's cargo-cult nomenclature, and it disrupts technical conversation to the point of uselessness.<p>Roy T. Fielding, who described the REST style, has an excellent blog post titled <i>REST APIs must be hypertext-driven</i> < <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...</a> >, where he lays out some ground rules for calling any given interface a REST API.
The story is very much the opposite in enterprise apps; I can't remember the last REST interface I saw, but we see SOAP interfaces every week, in new apps.<p>Unfortunately, SOAP isn't going anywhere. It's just not popular with Internet startups. Neither is ASP.NET.
My guess is that this is overblown a little.<p>Rails apps make RESTful services fairly easy, even if it doesn't usually cover the entire spectrum of RESTful actions. Many Rails (CRUD) controllers are going to have 4 RESTful actions built into that one controller/service, so a single app might have one RESTful service for each model (assuming it is exposed).<p>SOAP has been overtaken for sure, but I think that first pie chart set should show the <i>number</i> of services, not just the percentage. My guess is that the number of SOAP services may have grown, but the number of RESTful services just grew much more quickly.
I have to deal with SOAP APIs at work (Google, I'm looking at you) and they are seriously the bane of my existence. SOAP and the people behind it need to die a slow, painful and lonely death.
Unless you're using a framework like .NET where everything is done for you, SOAP is just too much trouble and complexity for simply data exchange. Especially if you're trying to consume it from Javascript or Flash.<p>I'm not sure how much of the "REST" in the pie chart is true REST, but POX and POJ is so much simpler and easier for cases where you don't need a full blown strongly-typed web services interface.
SOAP has 50x the features of REST. Even most REST advocates will accept that there are scenarios, where it's better to use SOAP. If you need complex security, reliability, addressing, etc. why not let Microsoft/IBM/Oracle do the dirty work?
RMM (Richardson Maturity Model) provides a good set of criteria for evaluating adherence of a web service to the Representational State Transfer Architectural Style.<p><a href="http://martinfowler.com/articles/richardsonMaturityModel.html" rel="nofollow">http://martinfowler.com/articles/richardsonMaturityModel.htm...</a><p>My guess is that 80% of those "REST" APIs are RMM-0.
i get the feeling that an important concern that prevents soap adoption is the bulkiness of the xml standard that it's based on. i hope that the efficient xml interchange standard will make that concern go away that.<p>solutions like thrift seem to reinvent most of what's been done with xml schemas and other standards around soap solely on the grounds of performance.<p>oh and it's surprising that json-rpc is not in this pie-chart. pure rest is not powerful enough to communicate a complex object structure.