Posts - 225
Stories - 0
Comments - 1327
Trackbacks - 416
Adam Nathan (rss)
Akash Jeevan Sagar(rss)
Z through A
Mar, 2006 (7)
Feb, 2006 (2)
Jan, 2006 (9)
Dec, 2005 (13)
Nov, 2005 (4)
Oct, 2005 (12)
Sep, 2005 (15)
Aug, 2005 (7)
Jul, 2005 (32)
Jun, 2005 (10)
May, 2005 (8)
Apr, 2005 (18)
Mar, 2005 (4)
Feb, 2005 (24)
Jan, 2005 (5)
Dec, 2004 (6)
Nov, 2004 (20)
Oct, 2004 (24)
Sep, 2004 (5)
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.
- We have several programmable HTTP client stacks:
- WinInet for unmanaged code.
- WinHTTP, also for unmanaged code but built to handle server-side use.
- XmlHttpRequest, which makes the former two stacks available to scripters. Apparently the folks at Google really like this one.
- System.Net for managed code that runs either on the client or the server.
- 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).
- We built IIS, a programmable HTTP server on top of HTTP.SYS that is used by a lot of people and Microsoft products.
- 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.
- 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.
- 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.
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.
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.
We're building deep support for XML in our languages, both in terms of LINQ and VB9's upcoming XML literal support.
- We built BizTalk Server, which is a giant XML transformation engine.
We added native support for XML 1.0, XML Schema, and XQuery to SQL Server to help people store and manipulate XML.
We added support for XML 1.0 and XSLT to Internet Explorer.
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.
We added XML data binding to our UI frameworks so our developer users could make XML pretty for people to look at.
We (finally) got a great textual XML editing experience in Visual Studio, including support for snippets and Intellisense.
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.
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.
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.
- Our HTTP stacks support all of the HTTP methods, not just GET and POST.
- IIS supports WebDAV (arguably the poster boy application of Hi-Rest).
- Windows Explorer supports WebDAV.
- Most Office client apps support WebDAV.
- Sharepoint supports WebDAV.
- Exchange supports WebDAV.
Our HTTP stacks support HTTP GET, including support for resource caching, content negotiation, etc.
Our XML stacks integrate with our HTTP stacks to allow you to consume XML using HTTP GET.
We built Internet Explorer, a generic tool that lets users make HTTP GET requests.
Most if not all Office apps let you insert URI and navigate/retrieve using HTTP GET.
SQL Server lets you map HTTP GET requests to database queries.
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).
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 on Saturday, March 18, 2006 3:24 PM
HTTP, XML, REST, and $100
Posted @ 3/18/2006 1:10 PM
Posted @ 3/18/2006 5:21 PM
How Tool Vendors Can Better Support REST
Posted @ 3/19/2006 8:02 AM
re: Going Down To The Crossroads…
Posted @ 3/19/2006 4: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?
Posted @ 3/20/2006 2: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.
(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).
Good questions to web platform developers
Posted @ 3/20/2006 9: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...
re: Going Down To The Crossroads…
Posted @ 3/20/2006 10: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.
Web Services, Boredom, and Wrong Guesses
Posted @ 3/20/2006 2:35 PM
As I read the latest debate about WS-This and WS-That, I find myself entering a deep state of ennui....
ASP.NET support for REST-ih Web Services (HTTP GET/POST)
Posted @ 3/21/2006 12:05 AM
ASP.NET support for REST/POX Web Services (HTTP GET/POST)
Posted @ 3/21/2006 4:15 AM
Posted @ 3/21/2006 7: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...
Lo-REST: This is your REST on Crack
Posted @ 3/22/2006 6:25 AM
Hi-Rest and Lo-Rest, two broken halves of the tower of Babylon.
Posted @ 3/22/2006 1: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
Posted @ 3/23/2006 10:08 AM
Posted @ 3/25/2006 9:32 AM
Posted @ 3/27/2006 12:58 PM
I enjoy it.
Oh, wait, *that* REST. Well, I have no rights to dare to comment on what either Don or Dare...
re: Going Down To The Crossroads…
Posted @ 3/27/2006 11:33 AM
Tim Bray chimed in with something practical. I tend to agree: