Robert McMillan of NetworkWorld has posted a very useful primer on the Representational State Transfer (REST) alternative to the SOAP paradigm for delivering webservices; if you need to hand someone an executive summary for why you don't need to retool your enterprise with expensive new servers and expensive new .NET clients, then this is the URL you will want to bookmark: A RESTful approach to Web services.

Why should you click that link? Who are these REST-ites and how do they know REST is the answer? I'll answer the last two. The REST paradigm was the brainchild of Roy Fielding, chair of the Apache Foundation, but Roy didn't invent it, he only gave it a name, and what he named is that same paradigm of distributed computing that gives the WWW it's incredible scaling power: SOAP/.NET is essentially remote procedure call, a functional session-state pipeline model that is only a shade above client server, and as is obvious by now, client server didn't scale worth beans compared to the RESTful document oriented World Wide Web. HTTP succeeds because instead of trying to track an expanding ad-hoc set of actions (services) on some limited set of (primative) datatypes, HTTP has only 4 verbs, GET, PUT, DELETE, POST which can be applied to an infinite collection of URI-addresses --- HTTP does not care what the data type is, it does not care if the data is valid, and it has to be tricked (by cookies) to behave in a stateful fashion.

So why should you click that link? Because REST worked, and if client-server had worked, why are you now reading this article over a web browser?