REST in peace, SOAP

SOAPLooks like the tide of the web API protocol war (if there ever was one) has shifted firmly in REST’s favor while SOAP has been forced back. Web developers have cast their votes, they want RESTful APIs.

Here is the distribution of the different API protocols and styles, comparing the situation in 2008 versus that of 2010, based on ProgrammableWeb’s directory of more than 2,000 web APIs.

SOAP vs REST, 2008 vs 2010
Source: ProgrammableWeb, May 2010.

Interesting enough, REST was already the dominant web API style even two years ago, and it keeps gaining ground.

If that’s not convincing enough, there’s Google to help us. The below graph should make it abundantly clear what the trend is.

Interest over time for REST API versus SOAP API:
Interest in REST API vs SOAP API
Source: Google Insights for Search.

So not only is REST the dominant API style by far, interest in it is growing rapidly, while interest in SOAP is declining.

Many of you probably knew this already, especially if you’re into web development, but it’s always nice to have to actual numbers to go with those assumptions, right?


  1. Completely agree with Joseph that SOAP cannot die off fast enough. Unfortunately, 15% is still a pretty big chunk of the pie. Maybe adding “, please” to the end of the title of this post might help.

  2. The title is a little misleading given that SOAP is still very much alive. It is certainly true that for publicly accessible APIs its use has declined but when it comes to private APIs SOAP is still the primary choice.

  3. Agree with Carson, internal SLAs are completely different and drive the use of data contracts. SOAP isn’t going anywhere, and REST isn’t a viable replacement for it on the enterprise.

  4. One big major place where SOAP is still used is enterprise. By default if you create a Web Service Project in Visual Studio, it uses SOAP internally.

    I am not sure but for using REST you need to use WCF which is again something devs would find difficult if you never used legacy web service development model in .NET.

    So people working in corporate sectors use only which is provided by .NET/Visual Studio. I bet many would not have even heard the name “REST”. Proof – my experience. My last application was SOAP since that was the “.NET way” at that time

  5. SOAP is not intended for hackers or cool web 2.0 startups

    It’s for hairy enterprise applications and pointy haired bosses who consume the typical marketing bullshit as measurement of industry standards and best practices.

  6. They do somewhat different things. REST is definitely easier to work with, faster to implement, and makes moving data around much easier when you’re talking about web applications and you own both sites or have a well published interface.

    SOAP on the other hand, does some things REST doesn’t. Create a good Web Service based on SOAP and get the wsdl right (or let your web application server build it), then just point Visual Studio to the WSDL and you nearly instantly have a very good way of talking between a desktop application and a back end server. The same holds true for several other programming environments.

    I use both. I’d expect there to be more REST based stuff because there’s more need for communication within web applications between the client side javascript and the back end data. That doesn’t mean SOAP isn’t powerful. There are far more cars made then tractor trailers — but you can’t really have an economy without big trucks.

  7. I have to echo some of the previous statements.
    REST is great for publicly consumable services, but for enterprise it’s still SOAP, and for many good reasons. And I’m willing to bet there are an order of magnitude more internal enterprise web-services than there are public facing ones. So if you had the REAL numbers I’m guessing SOAP is actually absolutely crushing REST.

  8. Is javascript there for JSON-RPC ?

    If so, I think its cool that it ever reached 7%, and unfortunate that it’s down a point.

    It can replace SOAP & XML-RPC while living happily alongside REST

  9. Interesting. This compares the APIs listed in the ProgrammableWeb, May 2010.

    Right now it lists 373 APIs using SOAP, out of 2220, roughly 17%
    REST has 1642, around 74%

    That is totally making sense, as REST is a style for the web, and SOAP is an RPC in disguise way of doing web services (not all, but the majority), and the majority of those may not be listed in that site.

    Anyhow, I wanted to make two little points clear here:
    1. REST is not simple. Many of the so called REST apis are not RESTful, actually. It has momentum and many people see it as a better way to work on web.
    2. That is why the searches are more on the REST side now, because of people trying to learn and understand about it. That means we have much more interest, not necessarily more usage or broader acceptance.

    So, this article points to a good suggestion: try to learn REST, the true way, as this is something that should be under consideration on new and current jobs. Still, that doesn’t mean that SOAP is dead, the charts above need to be read carefully.

  10. First, this story is not about REST (the arch style), but about HTTP (the protocol). Yes, “Straight HTTP” is now taking up the bulk of new API implementations. No, SOAP is not going away, but holding it’s own. Finally, as the stats show, SOAP was always trailing HTTP implementations, now the gap is wider.

  11. I’d like to balance the enterprise comments with my experience; REST is a serious approach in SAP enterprise software landscapes, and could have taken the prize in being the most-mentioned integration approach mentioned during the TechEd technical conference this week in Berlin for the world’s largest Enterprise software vendor SAP.

    For example:

    Sure, REST won’t be used by people just following what their tools dictate, but for people serious about enterprise integration in the long term, which definitely includes the vendors, partners and developers of SAP software, REST is very much alive and growing.


  12. As some of the commentators have mentioned before, majority of SOAP is within the enterprise, behind the firewall. This is because the tools used for coding/development automatically generate SOAP services/interface definitions/clients etc.

  13. How many of those self-proclaimed REST APIs are indeed truly so?
    I would argue that the vast majority is just tunneling RPC over HTTP without any support for hypermedia and very little support for content negotiation and the idempotent methods of the uniform interface.

  14. The only thing abundantly clear from these statistics is that more people want to call their APIs REST based than SOAP based.

    From my experience with APIs listed in the Programmable Web, having the REST tag guarantees absolutely nothing.

  15. I don’t know anything about soap or rest, but those who insist SOAP retains its validity in the enterprise are ignoring the fact that SOAP has declined as seen in the trend charts. This shows a wittling down of SOAP in the enterprise which means it is not viable in the long term.

Leave a Reply

Comments are moderated and not published in real time. All comments that are not related to the post will be removed.required