SOAP vs REST

The term "web service" generally describes an architecture of large scale networked software which wraps chunks of functionality in standardized APIs which are accessed via URIs over the web (that is, using HTTP).

The web service architecture that Erl [1] describes is based on a combination of XML, SOAP, WSDL and UDDI. In this scheme, a UDDI service is an XML based registry of web services which acts as a broker of metadata on those web services. A consumer would contact a UDDI service to search for a provider of a service based on metadata filtering. Once the consumer has chosen a provider from the UDDI service, they would discover the API for the corresponding web service by asking the service for its WSDL (which is also an XML format) record. They would then utilize the service by using the WSDL record to construct and send appropriate SOAP (another XML format) messages to the service, and interpret its SOAP replies.

An alternative web service architecture called REST is currently in use by entities such as Google, Yahoo, eBay, del.icio.us, Flikr, CiteULike, Twitter. REST was first described in a doctoral dissertation in 2000 by Roy Fielding, one of the principal authors of the Hypertext Transfer Protocol (HTTP) [2] and is based on several principles:

  • A service is divided into one or more resources, each of which is uniquely addressable via a URI over a network [2].

  • Clients and servers communicate via HTTP and exchange representations of the resource (documents which contain the actual data). This representation may be in any format, so long as both clients and servers understand it [2], although that format is typically XML [3].

  • The client should need to know only the URI of the resource and what it wants to do (typically PUT, POST or GET) -- it should not care what lies between it and the service (firewalls, gateways, caches, etc.). This is known as layering [2].

  • All communications between client and server should be stateless [2].

The REST approach differs from the XML/SOAP/WSDL/UDDI approach in that it trades many SOAP messages for many URIs. A SOAP based service operating on a single URI may offer a client many different potential messages or functions. A REST based service offers the same type of functionality by providing many different URIs each of which accept a limited set of functions (typically HTTP GET and PUT).

Advocates of REST claim, among other things that:

  • REST provides equivalent functionality to XML/SOAP/WSDL/UDDI.
  • Since REST is stateless, it is scalable: a set of REST requests can be spread across many servers.
  • Since URIs can be used in hyperlinks, and thus in hypertext documents, REST obviates the need for special service discovery mechanisms like UDDI.
  • Can reduce server load by supporting server side caching.
  • Less client side software is needed: one browser can access any REST service.