The pinnacle of simple versus complex may just be REST versus SOAP for Web Services. I over-dramatize, but there is a lot to take away from these two approaches to Web Services. I like this particular discussion because it helps me do two things: 1) Introduce a lesser known way to build Web Services (REST), and 2) Demonstrate why Occam’s Razor is never far off the mark.

Fair warning: I’m going to get technical and dirty in this blog post because it is required to make a point. However I suggest to hang in there with me and disregard details you may not immediately understand. It may be entertaining for you. I think it will be, anyway.

Let’s quickly summarize some definitions here so we can be on the same page with these terms. They can be confused at times, even among so-called “experts” in the field.

• HTTP: Defines how computers communicate with each other on the Web. HTTP specifies how a message that gets sent from one end point (e.g., a browser) to another end point (e.g., a server) and back again is built and transmitted. HTTP is an acrostic for HyperText Transfer Protocol. It’s the basic protocol for all web activity, like browsing web pages.
• SOAP: A specification for exchanging structured information (objects). This specification is adopted by a larger framework of specifications known as the Web Service stack, and is offered by many major vendors, including Oracle and Sun Microsystems. Can be used in conjunction with HTTP to provide for complex data exchanges over the same mechanism as web pages. Formerly an acrostic for Simple Object Access Protocol, simply named SOAP these days.
• REST: A style of software architecture. Already seen in how the web works, as its architecture as a whole can be considered RESTful. More of a philosophy than a technology per se. HTTP is in some ways an implementation of REST. An acrostic for REpresentational State Transfer.
• Web Service: Some computing service that is deployed on the Internet and consumed by another computer system. Technically, a Web Service could be consumed by people (a web site would fall properly within a set of all Web Services) but for the purposes of this discussion I’ll still to just those parts of the web that are more machine friendly than human friendly.

(If those definitions left you confused, think of it like this: HTTP is the basic language of the web, defined in a style that is REST, with SOAP providing another language on top of HTTP to provide a richer vocabulary. Web Services are computing services available through HTTP that provide some sort of service to other systems.)

With those terms out of the way, let me quickly give you a picture of the problem we’re trying to solve with Web Services.

At its most basic form, all a computer does is process instructions. When you turn on your computer, your processor is immediately bombarded with one instruction after another, processing them and returning each request with some result.

There are some cases where the processor for an instruction is not available on your machine. You can’t ask your computer, for example, for the search results Google would provide for a given set of terms. “But wait, yes I can!” you might retort. Oh, can you? Sure you can, by opening a web browser, typing Google.com in the address bar, typing in the terms in the search box and hitting the submit button. However, what is happening when you do all these things?

When you type Google.com in the address bar and hit enter, you are now sending the instruction to a processor on another computer. Specifically a computer wired to the Google.com name. The instruction is processed, and a response is put together and returned to the “caller” (the entity that initiated the request for information). Your machine is reduced to just a messenger. It isn’t doing anything other than sending a message to a Google server, receiving the response and displaying it to you.

Yeah. That’s it. Just a messenger.

A Web Service simply applies the same principle for accessing data on another processor. Rather than a person typing in a web address and getting back a web page through a web browser, a system process sends a message to another machine (addressed similarly to a web site) and receives a response for that message. This response tends to be the result of some calculation that the calling process couldn’t do on its own.

While the web was being developed and adopted, computers were already developing a way to do distributed computing all the same. These methods (that were not HTTP) were developed and evolved all on their own as well. The thinking behind them anyway. Sometime around 1999 and 2000, however, it dawned on many people that this web thing was kicking up. It was being successful. Why couldn’t it be successful for distributed computing?

SOAP and all related technologies came about because of this evolutionary thinking. It is the same rich capability, but on the foundation of the Web: HTTP. The reason SOAP had to be developed is because HTTP by itself doesn’t, by design, address the concerns that a messaging protocol is required to for distributed computing. Sure, HTTP is great for getting back a web page or uploading a video, but how am I supposed to build rich application programming interfaces (APIs) that are object oriented on such a simple protocol? We need something more. We need something like SOAP. We need SOAP.

Years after SOAP was defined and refined, and refined some more, some people started looking at it as a whole. Something wasn’t right about it. SOAP fit the bill properly for certain computing problems, but other times it seemed bloated. It seemed like a lot of stuff was required to make it work, when all I wanted to do was, in essence, expose a special kind of web page, one made for machines. This is when the RESTafarians were born. (I love that term.)

Why build all this SOAP stuff, when I could just expose the data through an address on the web? For example, I could define an address like http://silvanolte.com/add/2/2 and this would always return 2+2. I could dynamically add operands: http://silvanolte.com/add/2/2/2 and get 6 in response. (The SOAP way would probably be to define an endpoint such as http://silvanolte.com/add and in the request send in a complex SOAP-formatted message that describes the operands. The result would be an equally complex SOAP-formatted response that included the response of the calculation somewhere in all its metadata and bloat.)

This simpler thinking gave way to the idea of simple RESTful Web Services. It’s brilliant, and not exactly an evolution but instead a revolution in thinking and design. We all had a sense that the “simple” in SOAP was a misnomer. Now we had proof.

Once I read an article on RESTful Web Services, I was hooked. It was so simple. Many programmers and designers don’t like it just because it’s simple. For real! You don’t have to look far, either. Some of the big vendors like IBM and Oracle are selling SOAP style (heavy) Web Services hand over fist. It’s simply not always necessary.

REST, however, is a real winner. It provides the same result as a SOAP-based Web Service but typically in a much simpler implementation. API adoption can increase considerably if an HTTP-alone interface is provided. HTTP-based APIs are easy to implement on the server as well as easy to consume from a client.

Now, REST isn’t perfect. It isn’t the best solution for every Web service. For example, if the operands in my little addition Web service example happened to be bits of data that needed to be secure and private, then RESTful Web Services may not be the answer. Also, because SOAP is a proper protocol of itself, it can handle complex messaging requirements like attachments more easily than plain old HTTP (all that REST requires).

Look, it’s not that I’m not a fan of the complex. I actually love complex stuff. I have notebooks full of theoretical mathematics where I dig into the ugly, complex side of life. I just hate needlessly complex stuff. Key word being “needlessly.” That’s a huge source of lost money for many businesses. Web Services is probably high on the list of areas where companies are not being agile enough with their IT budgets and investments.

Yesterday I wrote about Occam’s Razor, which is a fancy way of referring to the KISS principle. You know, “Keep it Simple, Stupid.” This principle always has a place. It is very welcome when it comes to Web Services. It is why I chiefly prefer REST rather to SOAP, and now you can see why. Both technically, and in principle.