SOAP vs. REST

A quick apology to all the family members that are signed up to this blog. I promise to resume personal musings soon!

My class on Service Oriented Computing is discussing two paradigms of web architecture - SOAP (Simple Object Access Protocol) and REST (Representational state transfer).

REST is an architecture is a style that is used heavily throughout the web. Once we spent a lecture learning further about this and looking at examples, I was blown away at how often it's used. It would be like listening to a lecture on bricks and the types of bricks and the intricacy of brick laying and then stepping outside and look at a building. You're blown away at the new perspective you have for something that you took for granted your whole life.

REST is very simple. It's principles, (blatantly lifted from wikipedia) are:

• Application state and functionality are abstracted into resources
• Every resource is uniquely addressable using Uniform Resource Identifiers
• All resources share a uniform interface for the transfer of state between client and resource, consisting of
  • A constrained set of well-defined operations (HTTP GET, POST etc)
  • A constrained set of content types, optionally supporting code on demand
• A protocol which is:
  • Client-server
  • Stateless
  • Cacheable
  • Layered

Examples of RESTful web services include Flickr and Twitter.

At the time I read about SOAP in Chapter 4 of "XML, Web Services, and the Data Revolution," I thought to myself, "this seems very straight forward." SOAP uses the http transfer protocol with an XML payload. The payload, in turn, has a similar structure of an optional header plus a body - Easy (at least in theory.)

SOAP services require this structure for requests which isn't as easy to do as REST.