login      my ps      about      contact  



home instructor-led training online training blogs


Don Box's Spoutlet » Going Down To The Crossroads…

Going Down To The Crossroads…

Doug Purdy just pointed me to Tim Bray's response to Darryl Plummer's Web Services at a Crossroads.
 
What really intrigued me was Tim's last sentence:
 
Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.
 
Tim also mentions Tango, Sun's project to ensure that the Java stack interops with our stack, WCF. 
 
At the end of the day, both of our employers (Sun and Microsoft) need to make their customers happy, and both companies have a diverse customer base with a diverse set of needs.
 
In that spirit, I thought I'd try to catalog what resources MS has already committed to the XML/HTTP/REST technologies that Tim refers to.  This is by no means to imply there isn't more work to do (believe me, there is), but rather to checkpoint where the only vendor I can really influence is at.  I've written a follow up that speculates on where we can and should go in this space.
 
As fodder for where we should go, let's first look at where we're at:
 
HTTP (so far)
 
We've done a fair amount of work building and using general HTTP infrastructure that doesn't depend on nor mandate XML, SOAP, WS-*, or REST. 
 
  1. We have several programmable HTTP client stacks:
    1. WinInet for unmanaged code.
    2. WinHTTP, also for unmanaged code but built to handle server-side use.
    3. XmlHttpRequest, which makes the former two stacks available to scripters.  Apparently the folks at Google really like this one.
    4. System.Net for managed code that runs either on the client or the server.
  2. We built HTTP.SYS, which put a server-side HTTP protocol stack into the base OS, including kernel-mode URI-based dispatch to allow multiple processes to use a common TCP port (typically but not always 80). 
  3. We built IIS, a programmable HTTP server on top of HTTP.SYS that is used by a lot of people and Microsoft products.
  4. We built ASP.NET, which allows you to write HTTP handlers by implementing a two-method interface (IHttpHandler) or using a templatized ASPX markup file. 
  5. We built ASMX, which (independent from its SOAP support) allows you to declaratively map incoming HTTP requests to methods, including mapping URI components to method parameters.
  6. We built WCF (Indigo), which generalized the ASMX model and lets you do pretty much anything, including doing both straight HTTP and "dual-mode" HTTP that bonds two HTTP channels to allow arbitrary duplex messaging.
 
 
XML (so far)
 
We've also done a fair amount of work building and using general XML infrastructure that doesn't depend nor mandate SOAP or WS-*, although it does take advantage of our HTTP investments where appropriate.
 
  1. We built MSXML, an unmanaged XML stack that supports XML 1.0, XML Schema, XPath 1.0, XSLT 1.0, and COM-specific implementations of SAX and DOM.
  2. We built System.Xml, a managed XML stack that supports XML 1.0, XML Schema, XPath 1.0, XSLT 1.0, and a .NET-specific implementation of DOM . Rather than do SAX, we introduced a new push/pull model that the Java folks have since embraced.
  3. We're building deep support for XML in our languages, both in terms of LINQ and VB9's upcoming XML literal support.
  4. We built BizTalk Server, which is a giant XML transformation engine.
  5. We added native support for XML 1.0, XML Schema, and XQuery to SQL Server to help people store and manipulate XML.
  6. We added support for XML 1.0 and XSLT to Internet Explorer.
  7. We built Infopath, an end-user tool that makes it pretty easy to create UI over XML with or without an XSD (it can also use SOAP and WSDL if you want it to). The blog editor I'm using right now is an Infopath form. 
  8. We added XML data binding to our UI frameworks so our developer users could make XML pretty for people to look at.
  9. We (finally) got a great textual XML editing experience in Visual Studio, including support for snippets and Intellisense.
  10. The Visual Studio debugger now supports XSLT debugging so that XSLT users no longer need to channel the inner Prolog programmer to figure out why their XSLTs don't work.
  11. The Office team did a significant amount of work in Word and Excel to both make their own formats accessible as schematized XML data as well as to embrace the schemas that users already have.
  12. Most if not all Microsoft web properties expose (and sometimes consume) XML information, often in the form of RSS.
 
REST (so far)
 
This one is a bit tougher to catalog, because REST is a fairly subjective (and sometimes divisive) term.  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. 
 
Hi-Rest:
 
  1. Our HTTP stacks support all of the HTTP methods, not just GET and POST.
  2. IIS supports WebDAV (arguably the poster boy application of Hi-Rest).
  3. Windows Explorer supports WebDAV.
  4. Most Office client apps support WebDAV.
  5. Sharepoint supports WebDAV.
  6. Exchange supports WebDAV.
 
Lo-Rest:
 
  1. Our HTTP stacks support HTTP GET, including support for resource caching, content negotiation, etc.
  2. Our XML stacks integrate with our HTTP stacks to allow you to consume XML using HTTP GET.
  3. We built Internet Explorer, a generic tool that lets users make HTTP GET requests.
  4. Most if not all Office apps let you insert URI and navigate/retrieve using HTTP GET.
  5. SQL Server lets you map HTTP GET requests to database queries.
  6. All Microsoft web properties (including MSN, MSDN, and Live) are built on HTTP GET (even our APIs have Lo-Restful URLs thanks to Tim Ewald and friends).
  7. With the exception of our DAV support (listed above), most Microsoft technologies that update stores over HTTP tunnel server-specific update requests through HTTP INVOKEPOST the way the rest of the apps on the web do. Hence the need to distinguish between Hi-Rest and Lo-Rest
 
 
Posted Mar 18 2006, 03:24 PM by don-box

Comments

Don Box's Spoutlet wrote HTTP, XML, REST, and $100
on 03-18-2006 2:10 PM
Don Box's Spoutlet wrote Coming Out
on 03-18-2006 6:21 PM
Dare Obasanjo aka Carnage4Life wrote How Tool Vendors Can Better Support REST
on 03-19-2006 9:02 AM
Dimitri Glazkov wrote re: Going Down To The Crossroads…
on 03-19-2006 5:36 PM
What tha...? Don, I think your definition of Lo-REST puts it straight into the bucket with 99% of the Web.

But what about sessionless, stateless Web, opaqueness of URLs, request idempotence and transparency?

Shall we draw up a Mid-REST?
Julian Reschke wrote WebDAV
on 03-20-2006 3:58 AM
I absolutely agree that WebDAV is a very good example for "Hi"-REST, and also that -- in the past -- Microsoft has done lots of good things with it.

But today? There are tons of known bugs in both Microsoft's clients and servers, and apparently no intent at all to fix them.

It would be absolutely great if the WebDAV support in Microsoft's products would get the same fresh up as IE7 seems to get now.

Julian

(speaking as WebDAV server developer who needs to support Microsoft's clients, as WebDAV client developer who needs to support Microsoft's servers, and as active member of the IETF WebDAV working group, where no input from Microsoft has been seen for a very long time).
Alexis Smirnov wrote Good questions to web platform developers
on 03-20-2006 10:38 AM
Don Box (yes, that Don Box) is obviously trying to turn Microsoft's ship from WS to REST. Having spent significant efforts on WS, his courage has to be aplauded. In the process he is asking quesitons that should be...
pwb wrote re: Going Down To The Crossroads…
on 03-20-2006 11:24 AM
That's the problem with Microsoft, it's put out all that HTTP stuff but still doesn't have anything as simple, reliable and predictable as cURL.
A View from Elsewhere wrote Web Services, Boredom, and Wrong Guesses
on 03-20-2006 3:35 PM
As I read the latest debate about WS-This and WS-That, I find myself entering a deep state of ennui....
Bring It On wrote ASP.NET support for REST-ih Web Services (HTTP GET/POST)
on 03-21-2006 1:05 AM
Bring It On wrote ASP.NET support for REST/POX Web Services (HTTP GET/POST)
on 03-21-2006 5:15 AM
Davanum Srinivas' weblog wrote SOAP vs REST - Truce?
on 03-21-2006 8:52 PM
The RSS date tests reminds me of Sam Ruby talking about xsd:dateTime during Round 5 of SOAPBuilders interop and SteveL's effort to add a new interop test for timezones in xsd:dateTime. As for myself, I can't keep up with the...
Dimitri Glazkov wrote Lo-REST: This is your REST on Crack
on 03-22-2006 7:25 AM
Sacrificial Rabbit wrote Hi-Rest and Lo-Rest, two broken halves of the tower of Babylon.
on 03-22-2006 2:49 PM
Just because your application handles PUT and DELETE doesn't mean your application is even remotely restful. Even allowing for OPTIONS doesn't necessarily mean that your application is RESTful. Being a RESTafarian doesn't mean that you know how to make
you've been HAACKED wrote No REST In Lo-REST
on 03-23-2006 11:08 AM
Dare Obasanjo aka Carnage4Life wrote Hi-REST/Lo-REST Pushback
on 03-25-2006 10:32 AM
pwb wrote re: Going Down To The Crossroads…
on 03-27-2006 12:33 PM
Tim Bray chimed in with something practical. I tend to agree:
http://www.tbray.org/ongoing/When/200x/2006/03/26/On-REST
Kent Sharkey wrote My 2 cents on REST
on 03-27-2006 1:58 PM
I enjoy it.
Oh, wait, *that* REST. Well, I have no rights to dare to comment on what either Don or Dare...
Harry Bosch wrote XML editor is *not* great, it's broken.
on 04-11-2006 2:43 PM
re: "We (finally) got a great textual XML editing experience in Visual Studio, including support for snippets and Intellisense."

Well, no, not really.

It _could_ have been great if the keyboard handling hadn't been broken somewhere between beta 2 and the final release (and what on Earth was someone doing messing around with -- and breaking -- core technology like that _after_ beta???).

"Great" editors handle keystrokes correctly.
Don Box's Spoutlet wrote Spending the $100
on 04-12-2006 3:25 AM
Don Box's Spoutlet wrote Spending the $100
on 04-12-2006 3:26 AM
Neetu Rajpal wrote re: XML editor is *not* great, it's broken
on 04-17-2006 12:28 PM
Hello Harry,

I am the Program Manager in the XML team responsible for the XML Editor in VS2005. I would like to work with you to resolve the issues you are having with the XML Editor. If there is a bug you are encountering, I want to make sure we can adress it as soon as possible. Could you please contact me at "neetur at Microsoft dot com" or submit a bug via http://msdn.microsoft.com/feedback ?

Thanks Much
Neetu Rajpal
Program Manager
XML Team
Microsoft
Don Box's Spoutlet wrote Sam's Two Webs
on 04-21-2006 11:28 AM
Eike wrote Only GET / POST supported by many proxies
on 12-19-2006 5:23 AM
I know at least 4 (transparent!) HTTP-Proxies that I use at work/university that do not support any other than GET and POST.
mnot’s Web log wrote REST Issues, Real and Imagined
on 02-27-2007 9:20 AM
I think that most of the debate about REST focuses on the wrong things, leading developers down the garden path at the expense of their productivity and the success...
Sean the Nonbeliever wrote Don't drop the SOAP
on 05-10-2007 12:09 PM
So, there's been A LOT of talk from the Microsoft camp and elsewhere about the new importance of

Add a Comment

(required)  
(optional)
(required)  
Remember Me?


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation