lesscode.org

I’ve been on a language and infrastructure kick for the past month or so and posts have reflected that. Unfortunately this means I haven’t had the time to report on some of the excellent discussion around simplifying practices at the protocol and format level. Let’s run through some of this real quick:

Sam Ruby has been churning out good content on the practical benefits of HTTP and REST architecture, challenging SOAP/WS-* practioners to consider the immense benefits resource oriented design offers over the more popular service oriented (SOAP/WS-*) approaches. The Atom Wiki was slashdotted but he was able to push the troll-hoards over to an uneditable site due to HTTP’s redirect capabilities. He uses the occasion to illustrate one of the many basic features HTTP provides to accomodate massively distributed and un-coordinated environments that SOAP/WS-* completely ignores:

The foundation for most of this is rooted in the tantalizing phrase “hypermedia as the engine of application state”. If one views a wiki as a state machine, then being able to do a redirect is effectively changing the programming of the application.

The fact that I was able to do all this with but a single line of code — and using only the protocols and products that were already installed — was of great value to me yesterday. In fact, if one were predisposed to use such terms, I would go so far as to say it was of significant business value to me.

Sam provides more thoughts and conclussions in REST vs. API, which he sums up nicely:

At some point, you need to question the wisdom of having an API which abstracts away that which is important.

In the meantime, WS-* supporters are still trying to figure out how to fit the square peg of narrowly distributed systems architecture into the round hole of the web. Infoworld just published a story that tries really hard to slap some lipstick on the WS-pig:

Although the vendors backing Web services are confident they are properly addressing any kinks, Web services remains hobbled by issues such as standardization and WSDL complexity. To make matter worse, its impacts are growing, with both the .Net and Java development technologies focusing on Web services. Additionally, Web services is doing double duty as the lynchpin of the growing SOA trend.

And just in case there was any doubt that many leading vendors are completely clueless when it comes to providing tools to aid their customer’s operations moving to the web:

Microsoft’s Bixhorn emphasized the company’s planned Indigo technology as the answer to many issues cited with Web services. Due in 2006 in the Windows Longhorn client, Indigo removes the reliance on Web servers by extending beyond HTTP to support protocols such as SMTP, TCP, and REST (Representational State Transfer).

No, no, no! I don’t even know where to begin disecting the problems with this statement.

1. You don’t want to “remove the reliance on web servers,” you want to provide tools that let customers use it for what it’s worth. Web servers are good! We need to make more and better use of them.

2. Extending HTTP to “support REST” would be a truly interesting demonstration as REST is largely a description of the architecture HTTP facilities. UPDATE: it’s been pointed out that I may have mis-represented Krill’s intent here. I’m not sure I see a huge difference but in the interest of rational debate and all that…

3. <outrage>TCP?!!@%##! WHAT THE FUCK!</outrage>

I can only assume this was a horrible misprint or that Microsoft has an automated press statement request robot capable of combining a random set of acronyms with upcoming product names.

The blogosphere, at least, is injecting some sanity into the discussion. Mark Baker wrote a nice piece, Towards truly document oriented Web services, which does a good job of explaining why the web’s basic architecture has been and continues to be a perfect medium for “Web services” since long before the term was even coined.

There were also at least two enlightening articles on Atom’s potential as a SOAP/WS-* competitor. Bill de hÓra’s Atoms in a small world is a response to a computer weekly article making the following claim:

It is clear that there are lots of server-based applications (not blogs) that could work by syndicating packets of XML data to client applications (not RSS aggregators). These will not rival Soap/web services as a system for executing transactions.

Bill responds:

I don’t see why it would not be a good basis for enterprise concerns like messaging, authentication, or management interfaces. Atom, RSS and the Atom Publishing Protocol (APP) as a complement to REST could disrupt SOAP and WS.

I agree but have a slightly different take on how this will be most disruptive. In my opinion, REST and web architecture is just plain misunderstood. There’s a lightbulb moment that’s required to grasp it fully and it just hasn’t went off for a big portion of the business IT community. RSS and Atom are showing how following web architecture can yield huge benefits. These technologies are disruptive because it forces people to ponder whether the web in its basic, unmolested form may not be limited to web pages. If Atom can find a niche here than that’s great but I’m more excited by its potential as an agent for enlightenment.

Kurt Cagle follows Bill’s post with some truly excellent examples of how, in many cases, RSS/Atom can be superior to WS-* techniques in How RSS/Atom Is Replacing Web Services, which he ends with a demonstration of “good web thinking”:

While I suspect that this commentary will be poo-pooed by web services vendors, the history of the web makes me suspect I’ll be right in the end. RSS syndication has emerged in a largely ad-hoc fashion to fulfill a specific need - syndication - that seems to be an intrinsic characteristic and requirement of the Internet. Syndication in turn is simply a messaging protocol built around a subscription-oriented PUSH model. If you make the syndication format too complex for people to use (as I believe is the case with SOAP) then they will migrate to simpler formats as they become available. Because ATOM is blessed by both the IETF and the W3C and is seen as an open standard (whereas questions remain concerning the precise nature and implementation of SOAP) it will likely continue to gain the mindshare of developers and users alike.

To sum up, there’s been good stuff all around from the REST / web architecture guys and the WS-* death march continues on…

Comment RSS - Both comments and pings are currently closed.