REST and SOAP – Web services analogy

The World Wide Web is evolving from a sea of information to a service oriented marketplaces and Web Services are a critical part of this evolution.

What is a Web service?

A web service is a method of communication between two electronic devices over the World Wide Web.

W3C defines web service as a “software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” [1]

Web service diagram - Manish Chhabra

A more constrained architectural style for reliable Web applications known as Representation State Transfer (REST) was proposed by Roy Fielding. [2] In a REST-style architecture requests and responses are built around the transfer of representations of resources. A resource (e.g. Person) can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document (e.g. XML or JSON) that captures the current or intended state of a resource.

What is SOAP?

SOAP is a protocol specification for exchanging structured information in the implementation of Web Services. It uses XML for the message format. It is independent of the transport protocol (could be HTTP, FTP, TCP, UDP, or named pipes).

SOAP based services strictly define the format of messages passed back and forth. A SOAP message contains the data, the action to perform on it, the headers, and the error details in case of failure. Security is provided by WS-Security standards and is end-to-end. It supports identity through intermediaries, not just point to point (SSL).

SOAP provides a mechanism for services to describe themselves to clients (WSDL), and to advertise their existence (UDDI). SOAP also provides reliable messaging (WS-ReliableMessaging), that is a successful retry logic built in and provides end to end reliability through soap intermediaries.

What is REST?

Representational State Transfer (REST) is an architecture style for designing networked applications, that

  1. Involves clients and servers sending request and responses respectively.
  2. Request and response are built around the transfer of representations of resources.
    (e.g. request JSON representation of User)

REST recognises everything a resource (e.g. User, Lottery, etc.) and each resource implements a standard uniform interface (typically HTTP interface), resources have name and addresses (URIs), each resource has one or more representation (like JSON or XML) and resource representations move across the network usually over HTTP.

RESTful web APIs (or RESTful web service) is a web API implemented using HTTP and principles of REST. RESTful API separates user interface concerns from data storage concerns. It improves portability of interface across multiple platforms and simplifies server components by making them stateless. Each request from client contains all the state information and server does not hold client context in the session.

SOAP vs REST?

One of the major benefits of SOAP is that you have a WSDL service description. You can pretty much discover the service automatically and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth). Note that with version 2.0, WSDL supports all HTTP verbs and can be used to document RESTful services as well, but there is a less verbose alternative in WADL (Web Application Description Language) for that purpose.

With RESTful services, message security is provided by the transport protocol (HTTPS), and is point-to-point only. It doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

One of the major benefits of RESTful API is that it is flexible for data representation, for example you could serialize your data in either XML or JSON format. RESTful APIs are cleaner or easier to understand because they add an element of using standardised URIs and gives importance to HTTP verb used (i.e. GET, POST, PUT and DELETE).

RESTful services are also lightweight, that is they don’t have a lot of extra xml markup. To invoke RESTful API all you need is a browser or HTTP stack and pretty much every device or machine connected to a network has that.

Finally, which ever architecture you choose make sure its easy for developers to access it, and well documented.

Tagged , , ,

4 thoughts on “REST and SOAP – Web services analogy

  1. Mikaël DELSOL says:

    HI,

    Thank you for this reminder comparing SOAP and REST. I must admit I’m still attached to SOAP because I think REST needs to be more specified using a WSDL/WADL than it is used nowadays. Most of the REST WS are poorly specified, and as you say, we can’t programmatically generate a generic library to communicate with a REST WS.

    But I think I’ll have to use REST at least once to make my own opinion!

    Best regards,

  2. grails says:

    People usually criticize SOAP, saying it’s too heavy and slow. But for me, having a well defined contract is very important. With CXF today and Java EE, SOAP is very easy to do.

  3. sasha says:

    “RESTful API separates user interface concerns from data storage concerns.” – false assumption that SOAP can not do the same.
    “RESTful APIs are cleaner or easier to understand because…” – wrong set. It is easi(not easier) because of functionality it provides is limited. But with same set of functionality SOAP has same simplicity.
    It is clearly advertising of REST rather providing rational comparison.

  4. PeterH says:

    With SOAP you have a contract between the two parties.

    With REST you’ll have to implement such contract yourself in your code.

    For me SOAP is like a strongly typed language. REST is like PHP : quick to get something going.

    As for performance related to the size of the message that needs to be transported: People often assume that with SOAP huge amounts of very verbose XML needs to be transported. Technically this is true but in modern days the two endpoints will most likely use gzip compression and/or FastInfoset. This greatly reduces the size of the message, possibly to the size of compressed JSON. However some people argue that JSON is still somewhat faster to parse than is XML. This is possibly true but I believe the difference in parsing speed for most use cases is negligible. I’ve also seen tests where FastInfoset parsing outperforms JSON parsing. All in all arguments need to be reviewed in the light of the current state of affairs, not the way the world looked in 2005.

    I recently had to implement a web service where the request could become very large (several megabytes) and the reply even bigger. This works well with SOAP. Contrary with REST the conceptual idea is that you embed the request as part of URL and such approach of course only works for very small amount of request data. REST camp will say that you have two choices: (1) You embed your large data in a the body of a POST request but this is not really a ‘true’ REST way of doing things or you (2) change your design so that you send many questions rather than a single big question but such solution will of course create a lot more network overhead because of the roundtrip.
    I stayed with SOAP for this particular service.

    REST is fine and possibly the optimal choice for most scenarios but there are certainly cases where SOAP is a better fit, IMHO.

Leave a Reply