REST vs SOAP services – How I made my choice.

During a recent bout of product development, we were faced with a task of how to get massive amounts of financial data into our database. Bearing in mind, that our product is driven by client data which is pumped into it, we needed to find a way to expose a public facade, to authorised users only, in order for them to pump this data through. Oh, and our clients could prefer using other technologies for sending this data. i.e. .NET,Java, Ruby etc.

After much investigation I settled implement REST services through Spring. These were my top 3 reasons, of course I had a lot more, but these really stood out for me.

1. Low entry point and lightweight.

How many times have you heard this? But it’s true! Its just the HTTP stack you need. I unfortunately am constrained with time(aren’t we all?!) and I don’t really want the hassle of having to deal with massive unreadable SOAP packets, not to mention the toolkits I’ll need along with over-bloated configuration that goes along with it! I might be unfairly judging SOAP web services here, but I’ve never really had a pleasurable experience implementing SOAP in the past, especially when I have to keep in mind that the clients we’re relying on to use this platform could be clients who employ software developers of  varying degrees, so most of all I want to keep interfacing with our system as easy as possible.

2. Convention over configuration.

When developing REST like services, you have to adhere to simple URL’s otherwise no one is going to want to use it, and it makes things much simpler. I for one really don’t want to have to remember a massive URL just to add one record to a customer’s details. Adopting this approach really forces you to take a step back and think about how you represent your data, and how you plan to manipulate it. Doing that I’ve found has actually provided a better view of how our domain entities relate to each other, and their dependencies become transparent.

3. Authentication and Authorisation

I know many would argue that SOAP WS-Security is probably the most secure way to go, but to be completely honest, all my communication is going to take place over https and https only. What more do I need?  Implementing Authentication and authorisation over REST is just as secure, provided you make sure you don’t cut any corners, and not only that, it’s also simple if all you’re going to be doing is relying on already existing web authentication mechanisms. i.e. BASIC, FORM etc… I however have decided to implement my own authentication mechanism in Spring. Watch out for it in my next blog post.

4. Discoverability

OK, I know, I said top 3, but I couldn’t resist not mentioning this one. And its about being able to easily include self discovery of services while using REST services. And I must admit, this also played a big role in me making the decision to use REST for the kind of services we provide. REST in Practice really goes a long way in advocating explorable services through hypermedia, and I would urge anyone who is considering REST to give it a read. And if you find yourself racing through that book, then get yourself the REST API Design Rulebook which will help guide you in making the right choices when build your REST service.

Next up, how to authenticate the user in a REST kinda way….