Chase Seibert

Director of Engineering at Dropbox

When implementing web-services, the two most popular paradigms are SOAP and REST. Prior to REST becoming a formal standard (though it's still very loose), many so-called web-services were implemented as XML/CSV/JSON/something over HTTP. Those could be fairly categorized as REST-like, also.

Popularity

Though SOAP was formalized far in advance of REST, REST has become more and more popular in recent years. Take a look at the Google search trends for each:

SOAP = Red, REST = blue

Trade-offs

What were some of the problems with SOAP that REST was designed to improve on?

  • Provides improved response time and reduced server load due to its support for the caching of representations
  • Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
  • Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
  • Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
  • Provides equivalent functionality when compared to alternative approaches to communication
  • Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
  • Provides better long-term compatibility and evolvability characteristics than RPC.

The bolded points are aimed directly at SOAP. With SOAP, you generally need some solid framework support to consume web-services easily. Specifically, many platforms have a way of generating stubs from a WSDL, and then helper methods to allow calling the web-service with those stubs.

Discovery

In practice, all SOAP services publish a WSDL that allows frameworks to auto-generate sample code to consume the service. In practice, virtually no REST services publish their equivalent, WADL.

In Java and .NET, the framework tools are pretty awesome. It's not unreasonable to expect an experienced developer to get up and running with a new SOAP service in just a few minutes on a platform with good SOAP tools.

On other platforms, SOAP can be a pain. You would not want to try to call a SOAP service from JavaScript, for example. While there are libraries that help, there are some fundamental mismatches. JavaScript is dynamically typed, where-as SOAP is strongly types. In JavaScript, you generally do things on the fly at run-time. Most SOAP tools pre-package stubs ahead of time. It's a more natural fit to call a REST service via an HTTP Ajax request.

Developers are lazy

I think that's what it comes down to. If your platform has really good SOAP AND REST tools, you will get up and running much faster using SOAP, due to auto-discovery. If your platform has poor/no SOAP tools, you will have to "discover" the particulars by reading the documentation, and you will need to make calls manually or via your REST framework tools. In that case, REST is much easier to implement.

REST is great. It really is simpler and more scalable. I just think they dropped the ball by not pushing WADL harder.