Summary
The REST architecture style includes several points of interest. One of them is a "uniform" or "fixed" API. There is a subtle issue with that. I don't really think that this concept is what REST is all about.

---

Advertisement

Save Our Architecture... Arguments

I guess there are many recurring arguments of REST vs SOAP for SOA. Before I get started, I'd like to make sure my view point on these arguments is clear. REST vs SOAP is mostly about ignorance based arguments. REST is an architecture style for implementing remote system interfaces. SOAP is about interoperability in those remote system interfaces. There have been some rather hilarious blogs, of late that describe some of the insanity that revolves around the "SOAP BOX" that WS-* proponents tote around. The RESTarians are having a lot of fun with it all.

Without getting into a big SOAP vs REST debate, I'd like to focus on some of the discussion that I've had with REST proponents about the "uniform API" of HTTP being an attribute of REST style architecture.

In many RPC systems, there is a uniform API utilized to invoke operations between systems. The "INVOKE" operation has a single parameter, the argument list, and a single return value, the operation's result. One can argue that RMI/Jini, CORBA, sunrpc, COM/DCOM and others are really RESTful systems as well. However, there are more words and acronyms in the typical REST argument. So, it gets a bit heated to just use the "uniform API" mantra as a point of argument.

An interesting attribute of HTTP is that it doesn't "cause" an application to be RESTful. It merely (or usually) allows RESTful systems to be created by providing a structure with less freedom for mistakes in design. That is, if you understand what HTTP, the protocol specification, documents for the GET, POST and PUT operations, and you grasp, and adhere to the "state transfer" (not transport) mechanics, and you understand how to create URIs that are referring to resources, not "operations" (because GET, POST and PUT are the operations) most of the time, you can create a RESTful system.

There's More to REST (on) than HTTP

The REST arguments are about simplifying system interface needs, to make certain types of things easier to do. TCP was the initial go at this, years ago. Simple guaranteed stream of bytes transported from one place to another. The issue was, that "transport" requires recurring programming structure/support in each software system, to get to the point of having the ability to "transfer" something. That is, in order to transfer a known bit of information from one place to another, you need a bit more protocol to enumerate what's being transferred in the bits that TCP is transporting between systems.

Early protocols like SMTP and FTP were designed for transferring specific types of information from one point to another. What we see in those protocols, is the basic issue that HTTP has tried to solve. That is, how can we have one protocol to transfer "anything". A predominate issue with SMTP, is that there is no sender authentication. A recurring issue with FTP is that there is a need for binary vs text transfer indication by the user because FTP has no idea what you are sending, and the MSDOS vs UNIX line termination issue is still around.

HTTP provides (now) the ability to cause the user to authenticate for access. HTTP solves the text vs binary issue by saying that everything is "binary" and the Content-Type: header tells the user/application receiving the transferred "information" what type of data it is to deal with content formatting issues. MIME was already being used in SMTP to make attachments possible, so its use in HTTP wasn't anything new.

An old friend of mine, Ned Freed, was responsible for the development of MIME. I still remember the day he told us that E-Mail would never really be useful for anything! I have to give him a break on that. He had been burdened with BITNET which truly was not useful!

In the end, the fact that REST uses HTTP, is nothing particularly amazing. There are some really old design/architecture concepts involved in the design of HTTP, which have fallen out of years of experience with other systems, where similar concepts have existed for some time. The formalization of GET, POST and PUT (and the others which are less visible) operations in HTTP and the specification of those operations is really nothing much different than what was already possible with the combining of a few tools.

From my perspective, the important part was the creation of the single HTTP service to perform all the tasks in one process. The tying of the operations (GET, POST and PUT) with the URIs was similar to the SMTP "Mail From:" and "RCPT TO:" where a namespace had been created to indicate a particular resource (a users mailbox).

The Servlet mechanism in Java based HTTP servers (and similar scripting/control facilities in other HTTP servers) allows the 3 operations to be used in a compartmentalized way which creates the "resource" layer that the server reveals through the URIs that it accepts. This is just good OO design supporting the HTTP URI model.

Without all of these pieces together, HTTP would not be any more useful than a simple RPC scheme. You'd have to write the same amount of code. REST based architectures are really benefiting from many attributes of the HTTP implementations more than it is benefiting from the protocol itself.

These same architectural benefits are available in many Java based platforms which have utilized good OO principles and which provide container semantics similar to the servlet model where Java's dynamic code loading facilities make it easy to plug in code at runtime.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.