It's often said that history repeats itself - and by studying history we gain better insight into our current (and future) society. In the late 1800s the telegraph was immensely popular, but telegraphs only connected telegraph offices. Messages still had to be transcribed into a paper format and delivered to the appropriate person. Delivering them was a problem due to transportation costs, personnel costs, and time lost between transcription and delivery.

Pneumatic tube systems were developed to transport documents within a building or across an entire city (London had a tube system that traversed well over 50 miles). They were quite successful because they were easy to use and fairly reliable. Senders placed their document(s) within a small capsule that they deposited into the tube, and the system transported the capsule using compressed air. These systems had several built-in benefits - simplicity, security, and shared semantics - and they provided closed, point-to-point connectivity. Most of the tubes ran underground or within walls and were frequently shielded by cement or thick iron ducts; intercepting a message required a far different set of hacking skills (some of which may have involved explosives and pick axes). As with the Web today, documents were most vulnerable at the points of transmission and receipt. Semantics weren't an issue since senders and recipients usually worked for the same company or resided within the same locale (the fact that senders and recipients were humans capable of thinking, reasoning, and interpretation was also a big plus). Pneumatic tube systems proved to be so popular that they were used until the mid-1980s in France. Smaller systems are still in use today at hospitals, banks, and large grocery outlets.

Although tube systems have become virtually obsolete, we can still draw some interesting comparisons to today's popular view of Web services. Most implementations require SOAP for transport, WSDL for describing interfaces, and (optionally) UDDI for publishing/locating the service. Like the old pneumatic tube systems, messages must be placed into a "capsule" (in this case a SOAP envelope) prior to transmission. Secure messaging via HTTPS helps ensure that messages aren't tampered with prior to delivery (no cement or ironwork needed). While SOAP has become a de facto standard for Web services communications, it's far more difficult to understand than a simple pneumatic tube system capsule. SOAP is frequently referred to as a highly flexible application-level protocol that supports virtually any message exchange pattern (MEP), any protocol, any method or type of data. Highly flexible initiatives can be a lot like the paper clip - easy to understand and use until someone bends it out of shape, negatively impacting its interoperability.

A set of simple, universally understood and implemented methods can provide a viable alternative (or extension of) a SOAP infrastructure. The pneumatic tube system was so popular because of its simplicity and ease of use - all tube implementers shared a common set of core methods. The Web shares this trait and is based on a core set of simple methods (POST, GET, PUT, DELETE) that have been widely deployed and used on a global basis - you probably use most of them daily (via your browser) without a second thought. The wonderful thing about these methods is that they're universally agreed upon and highly scalable (the Web itself is built on them). Since we all agree on how these methods operate, why not utilize them for Web services?

This is, in essence, the point made by REST advocates. REST (REpresentational State Transfer) is an architectural style, not an application-level protocol (like SOAP), first described by Roy Fielding (see www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). The REST architectural style recommends using the common HTTP methods (POST, GET, PUT, DELETE) used by the Web itself. This style is highly interoperable since clients need only understand HTTP - there's no longer a requirement (or expectation) to use specific enveloping rules (e.g., SOAP) or invoke proprietary methods (e.g., getStockPrice). Instead of building and sending a SOAP message, clients simply POST a simple XML message (containing only relevant application data) to a specific URI. The URI is linked to an internal method that processes the XML and returns an appropriate response that contains one or more additional URIs, enabling the client to drill down and obtain more detailed information or gain access to additional resources and methods. Sound simple? It is - REST architectural styles can simplify and extend SOAP infrastructures to organizations unfamiliar with or unable to use SOAP. A REST architectural style can also be used to wrap repositories that require knowledge of both SOAP and repository-specific APIs.

While REST may provide some insights into designing highly interoperable systems, some of the limitations of HTTP (such as WSDL-like descriptions, multihop routing, and reliability) have yet to be addressed. Providing SOAP-enabled methods within a RESTful architectural style appears to be a good approach for ensuring the highest levels of interoperability.

Pneumatic tube systems were a success because they provided a simple tool for effective message distribution. Initiatives such as SOAP and REST will continue to be successful due to their simplicity and ease of use (they're also immune to lost messages due to a rat's nest stuck in the pipe). Like the Web, tube systems continue to evolve - some scientists propose them for transporting people instead of documents. Might we see something similar using the Web or Weblike technologies? Beam me up, Scotty. Oops - 404: Person Not Found.