Note: This article originally appeared in the January, 2010 edition of TEQ Magazine.

If you were given the opportunity to travel back in time for one day, how would you use it? Would you try and stop a famous tragedy? Would you go back to witness an historical event, like the Beatles’ first appearance on Sullivan? Maybe you’d prefer to relive your happiest day.

For me it’s a no-brainer. I’d use the time machine to go back six months and stop myself from using SOAP in my last software project.

Last year my company developed warranty management software for a company that makes siding for homes. Our application manages most of the claim process from filing to payment, but one part it doesn’t handle is the scheduling of the home inspection. A third-party handles that step, and they have their own application that my team’s program had to interact with.

To get our applications talking, we decided to use web services with SOAP. It made perfect sense. After all, our situation was exactly the kind of data-exchange-over-the-web type of application that SOAP was designed for. We’ve used it before, and although we’ve never loved it, it still seemed like the best tool for the job.

But what started out as a two-week task turned into three months of debugging, handwringing, and self-doubt. Nothing worked as it should. First our Java application couldn’t connect with the proprietary authentication technique the other company was using. (Although SOAP itself is a standard, it can work with dozens of “sub-standards” which aren’t all well supported.) Then we had problems with decoding image attachments, data validation, XML file size limitations, and server conflicts with other programs. At one point the web service even failed when the other system’s clock fell out of sync because of daylight saving time.

SOAP’s not an acronym anymore, but when it was, the “S” used to mean “simple”. Ha! That’s like calling a cystoscopy a “simple procedure”. Sorry Dr. Smith, but what you once described to me as a simple procedure is actually the least simple thing I can think of. And the only thing more painful was that time I used SOAP in a warranty management application.

SOAP has good intentions, and with enough effort it can be made to work well. But the problem with SOAP is that it’s built on top of many layers, and with each new layer comes a new set of complications. SOAP tries to be an all-encompassing protocol, and although this makes it powerful, it also makes it complex.

Fortunately there’s an easier way of exchanging data between programs over the web. It’s called Representational State Transfer, or REST. Unlike SOAP which is a protocol, REST is more of a general approach to sharing data between a client and server. A RESTful web service forgoes complicated protocols, and instead takes advantage of HTTP’s underutilized features.

Imagine you run a business that rents camels by the hour. In addition to allowing reservations on your web site, you want to open your system to third party brokers. The brokers use their own software to compare prices and make reservations, and they’re not going to rent out your camels if you don’t give their software a way to hook into yours. You decide to make your reservation system available to theirs via a RESTful web service.

With REST, you expose your software’s functionality via meaningful URLs, and you take advantage of HTTP’s “verbs”, which are called actions. For example, if a broker wanted to check the availability of your two-humped camels, their software could issue a GET request of http://www.carav.an/camel/hump/2. To make a reservation for a camel named Gobi on April 12th, their software could issue a POST request of http://www.carav.an/camel/gobi/2010/04/12. To check on the status of reservation #123, they could issue a GET request of http://www.carav.an/reservation/123, and to cancel that reservation they could issue a DELETE request of the same URL.

Unlike SOAP which is limited to XML, RESTful web services can share their data in any number of formats, such as XML, JSON, or CSV. REST replaces complexity with simplicity, and it takes better advantage of existing methodologies instead of inventing its own. Although it lacks some of SOAP’s strengths, such as a unified way of defining your interface, it makes up for it with its ease of implementation.

The next time you develop a web service, consider this alternative to SOAP. Although we can’t travel backwards through time, at least we can use REST to save it.