Understanding the differences between SOAP and REST

When I started coding, SOAP services were booming. Everyone used to use SOAP. And SOAP was great, it worked really well for the enterprise applications that I built. As my team was debating on should I use SOAP or REST, I read a lot about which one makes sense.

Here are somethings you need to consider when choosing SOAP or REST

REST is more of an Architectural pattern than a protocol. It follows a set of constraints that we need to adhere.

  • Performance - how does my component interaction affect performance
  • Scalibility - should be able to support large number of components
  • Simplicity - of a common interface
  • Modifiability - meets evolving needs of the systems
  • Portability - of components by moving program code with the data
  • Reliability - resistance to fail
  • Visibility - clear communication between components

Key actions in REST

  • post - adding data, posting tweets, adding messages to message board
  • get - to retrieve data, get user, get employee list
  • put - to save an update to the URI
  • delete - to remove a specified resource

Key advantages of REST

  • Fast (smaller messages and no extensive processing is required)
  • No expensive tooling is required
  • Closer to web
  • REST is not restricted to XML format. REST web services can send plain text, JSON, and also XML.

One key thing with SOAP is the tight integration between Client and Server. A SOAP client works like a custom desktop application, tightly coupled to the server. There’s a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it’s easier to ascertain if the contract is being followed.

A REST client is more like a browser. It’s a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don’t violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there’s less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything it will be using, or it won’t even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side.

Finally, SOAP and REST can’t be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn’t SOAP.