Save Our Architecture... Arguments

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

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.