REST and SOAP: what and when | Division by Zero

Architecture, security and coding

REST and SOAP: what and when

REST and SOAP: what and when

Written by Division by Zero

Thursday, 01 April 2010 08:34

There has been a great debate between SOAP and REST services over the past years. It seems that the truth is in the middle: both are valuable and we must choose the technique where it is appropriate. Here's a short description of the two and where we should use them.

REST

REST is heavily based on the HTTP protocol. Actually it is the HTTP protocol plus data. This means that you'll get all the benefits of HTTP and the solutions around it, like security, but it also means you must use HTTP. The data can be formatted as XML, JSON, Atom, etc. HTTP defines the operations that you get over the data (GET, PUT, POST, UPDATE, DELETE), so you're only worry is the data. Every service will work in the same way, only the data will be different.

The reuse of many standards and widely used HTTP protocol makes REST an easy and understandable protocol. It's simple to develop with almost all frameworks. Even for .Net. It seems to be more work, but I believe it will be even less when you get the hang of it.

SOAP

SOAP is basically a RPC protocol. It's based on things like CORBA and COM+. SOAP is protocol independent, which means that you can use it over HTTP, TCP, MQ or another protocol of your choice. Using SOAP you will have to define ll the operations and use a WSDL. This makes the service harder to understand and every service needs to be interpreted in it's own way. The beauty of SOAP is WS-*, the addition of different headers. Using these headers can give you security and guaranteed delivery among other things.

When to use what

The security of REST is on protocol level, thus on connection level. SOAP is able to provide security on message level, or even part of messages. If you're communication has to be secure, for example financial data, SOAP is the best choice.

REST is simple and readable. Trough the power of HTTP it is extensible. The URI of the service makes it unique, therefore service versioning is easy. If you want to publish easily usable services, for example on the web, REST is probably your best choice.

There's no golden rule, but for corporate solutions SOAP is probably the best choice. For public services REST would be a good choice.

Tags:

Related Articles

Add comment

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams

© 2009 - 2012, Division by Zero

Template based on the empire template by joomlashack

This work by Division by Zero is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Netherlands License.