Give It a REST - Software Development Times On The Web

Give It a REST
By Larry O'Brien

January 15, 2007 — I’ve decided to stop being polite about the WS-* stack. I shipped my first XML-over-HTTP solution more than seven years ago. SOAP didn’t exist, so we just used servlets to parse requests and respond appropriately, a technique that today is called “Plain Old XML” (POX). We did lots of things that, in later years, would be considered wrong—we didn’t use namespaces, we didn’t fret a great deal about validation, we constructed our XML using string-processing commands—and, of course, there were pain points in what we developed. Yet we shipped.

In 2000, I first heard the refrain that’s become so familiar since: The coming wave of vendor-provided tools would simultaneously simplify development and enable new scenarios. Simplify? Constructing and parsing XML documents was even then about as hard as falling off a log, but anything can be made easier. The new scenarios envisioned in the year 2000 centered around guarantees: delivery, execution (via transactions) and privacy (via encryption). Quicker than you can say “https,” these were then bundled together into a “distributed trusted trading partner supply-chain.” In the face of such an important-sounding thing, I began my sorry history of capitulation. POX worked well for me and Roy Fielding’s thesis (roy.gbiv.com/pubs/dissertation/rest_arch_style.htm) seemed eminently logical, but, geez, if you’re trying to program a supply-chain with distributed trusted trading partners, then maybe WS-* has its advantages.

Every year since then, it’s gone the same way: I worked on systems and, invariably, those that used POX and REST had very little pain about tooling and debugging. Those that used WS-* protocols generally went fine—as long as everyone used the same tool set. If they used .NET exclusively, great. If they used Axis exclusively, great. If they used Random Programming Language exclusively, great. But what about when worlds collide? When you try to point a Java-based tool at a .NET-generated WSDL file or vice versa? Trouble.

I’ve advocated REST and POX in this column over the years, but never at the expense of WS-*, for which I always gave a “to be sure, complex scenarios may call…” deferral. No more. The final straw came when I found myself tracing a

WS-* service call with a network sniffer. A network sniffer! In order to see why my multihundred-dollar, best-in-breed tool wasn’t able to interact with my “simple” Web service! What is this, NetWare in 1992? With REST, the URI endpoint for the communication is universally reachable—point a browser at it to see the client view, toss a server page in there to see the server view. With POX, you’re just a cut-and-paste away from parameter and response validation and automation.

Do problems about types and semantics arise with REST and POX? Of course they do. But, and this is the point that is skipped over by the WS-* salesmen, the same problems arise with WS-*. The very point of a service-oriented architecture is that you’re cleaving a very complex domain into a set of subdomains with different responsibilities; the complexity of negotiating what travels across the borders between those domains is an essential, not accidental, characteristic. In the face of such complexity, the best architectural choice is the one that provides the most visibility, so that problems and ambiguities can be quickly identified and addressed.

In the case of function calls and programming languages, I take this principle to advocate for explicit typing. In the case of service calls over the network, this principle advocates for REST and POX. This initially may seem contradictory, but not when you consider another fundamental principle of network service design: Web services must be coarse-grained. For in-memory functions, a typical program contains calls to dozens or hundreds of different functions, and outside of embedded systems, there’s little penalty and generally some clarity in designing fine-grained functions. In that situation, explicit type information (and unit testing, documentation, etc.) help with comprehension.

The cost of transporting a call over the Internet, though, is huge. Each call in a properly designed service-oriented architecture involves significant preparation and post-call work (UIs based on AJAX are dramatic, and kludgy, exceptions). The vast majority of developers understand the issue and design coarse Web service calls. When parameters or responses are expressed in large, hierarchical, text-based chunks (in other words, as XML documents), the added benefits derived from automating the parameter types are minimal. As for the rest—security, transactions, discovery and so forth—the WS-* forces have failed to prove their case. WS-* is harder, not easier, than REST to implement. It’s less, not more, interoperable. It’s the product of vendor committees, not problem-solving developers. For more than half a decade they’ve promised, “The ease-of-use breakthrough will come real soon now.” It hasn’t. The debate should be put to REST.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/1/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE

ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH

Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA