Tim Bray has written some good food for thought in his post WS-Gartner where criticizes some of the party-line praise of WS-* technologies as the future of building services on the Web and calls for vendors to provide better tooling and developer support around simple XML/HTTP/REST technologies.

Don Box has written two good responses from the perspective of a Microsoft employee. The first Going Down to the Crossroads outlines the various ways Microsoft supports working with XML, HTTP and REST. One thing I particularly like about Don's post is the following excerpt

To get a more accurate picture of what we've done so far, I'll break this category in two: Lo-Rest, which is the use of HTTP GET (or equiv) for information retrieval/query, and Hi-Rest, which is characterized by the use of HTTP PUT and DELETE (or equiv) for doing update.

I like the distinction between Lo-Rest which I've also seen people call Plain Old XML over HTTP (POX/HTTP) and Hi-Rest which is actually rare in practice with notable examples being WebDAV and the Atom Publishing Protocol. Don isn't the first person I've seen make this distinction using this terminology. Nelson Minar of Google was the first person I've heard make the distinction between Hi-Rest and Lo-Rest In his talk Building a New web Service at Google at last year's O'Reilly Emerging Technology Conference.

Don's second post in response to Tim Bray is entitled HTTP, XML, REST and $100 and he uses what has become a common tactic by Microsoft bloggers to get prioritizations of feature requests from our users. He asks how Microsoft should better support building RESTful web services including better support for HTTP and XML. Specifically he wrote

You have $100 engineering dollars to spend. No matter how many millions we'd actually wind up spending, we use $100 as an easy number for people to keep in their heads.

There are well over $100 dollars worth of features you want.

The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.

So how would you allocate resources?  Here's my  first stab with not a lot of deep thinking [after all, I'm still in Las Vegas] ;)

• $40 - better support for consuming XML in the browser. Specifically Microsoft should follow the lead of Mozilla and implement E4X in the browser.
  
• $30 - first class support for building RESTful (i.e. HTTP-centric) web services in Windows Communication Foundation [formerly Indigo]. It should be just as easy for a developer to build a service that exposes SOAP/WSDL as it should be to build one that exposes PlainOldXML, supports the core HTTP methods and some of the more esoteric but useful aspects of HTTP such as content negotiation which no one really supports well today. My ideal scenario is that it should be brain dead easy for me to build a WebDAV server on top of WCF/Indigo. Of course, I assume that supports for multiple serializations beyond XML such as JSON or binary formats is also a given.
  
• $20 - add the functionality in XLinq to C# as well as VB.NET. I think it would be really dumb that in the next version of Visual Studio I'm going to have to switch languages to VB.NET if I want to use a programming language that has integrated support for XML.
  
• $10 - add support for some non-W3C XML technologies in Microsoft's core XML stacks (i.e. MSXML and System.Xml). I'd love to see native support for RELAX NG or Schematron in Microsoft tools.
  

I'd write more but my girlfriend is giving me that look that says I've already spent too much time in front of the computer. :)