About UsCommunityTrainingContent DevelopmentContact

Blogs
Pluralsight
Craig Andera
Mark Baciak
Don Box
Keith Brown
John CJ
Tim Ewald
Vijay Gajjala
Kirill Gavrylyuk
Ian Griffiths
Martin Gudgin
Jim Johnson
Joe Hummel
Mark Michaelis
Matt Milner
Fritz Onion
Jeffrey Schlimmer
Aaron Skonnard
Dan Sullivan
Herb Sutter
Mike Vernal
Doug Walter
Jim Wilson
Mike Woodring

My Links
Home
Contact
Login

Blog Stats
Posts - 225
Stories - 0
Comments - 1327
Trackbacks - 416

VSers
Anson Horton(rss)
Chuck Jazdzewski
Cyrus Najmabadi(rss)
Dan Fernandez
Gareth Jones(rss)
Gus Perez(rss)
Herb Sutter(rss)
Jack Greenfield(rss)
Jay Bazuzi(rss)
Keith Short(rss)
Matt Warren(rss)
Peter Hallam(rss)
Scott Wiltamuth(rss)
Steve Cook(rss)
Stuart Kent(rss)

WinFXers
Adam Nathan (rss)
Aditya Bhandarkar(rss)
Akash Jeevan Sagar(rss)
Bruce Williams(rss)
Chris Anderson(rss)
Daniel Lehenbauer
Dave Green(rss)
Dennis Pilarinos(rss)
Dharma Shukla(rss)
Doug Purdy(rss)
Doug Walter(rss)
Filipe Fortes
Greg Schechter
Henry Hahn
Hervey Wilson(rss)
James Conrad(rss)
Jeff Schlimmer(rss)
Jim Johnson(rss)
Jurgen Thelin(rss)
Karsten Januszewski
Kavita Kamani(rss)
Kenny Wolf(rss)
Kirill Gavrylyuk(rss)
Lauren Lavoie
Martin Gudgin(rss)
Mike Vernal(rss)
Nick Kramer
Omri Gazitt(rss)
Rob Relyea
Savas Parastatidis
Steve Maine(rss)
Tim Sneath(rss)
Yasser Shohoud(rss)

WinFXies
Aaron Skonnard(rss)
BenjaminM
Christian Nagel(rss)
Christian Weyer(rss)
Clemens(rss)
David Chappell
Ingo Rammer(rss)

Z through A
Chris Brumme(rss)
Jan Gray(rss)
Jon Udell
Nick Gall(rss)
Paul Graham(rss)
Petzold

Archives
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)

Image Galleries
People



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 on Saturday, March 18, 2006 3:24 PM

  • # HTTP, XML, REST, and $100
    Don Box's Spoutlet
    Posted @ 3/18/2006 1:10 PM
  • # Coming Out
    Don Box's Spoutlet
    Posted @ 3/18/2006 5:21 PM
  • # How Tool Vendors Can Better Support REST
    Dare Obasanjo aka Carnage4Life
    Posted @ 3/19/2006 8:02 AM
  • # re: Going Down To The Crossroads…
    Dimitri Glazkov
    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?
  • # WebDAV
    Julian Reschke
    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.

    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).
  • # Good questions to web platform developers
    Alexis Smirnov
    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…
    pwb
    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
    A View from Elsewhere
    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)
    Bring It On
    Posted @ 3/21/2006 12:05 AM
  • # ASP.NET support for REST/POX Web Services (HTTP GET/POST)
    Bring It On
    Posted @ 3/21/2006 4:15 AM
  • # SOAP vs REST - Truce?
    Davanum Srinivas' weblog
    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
    Dimitri Glazkov
    Posted @ 3/22/2006 6:25 AM
  • # Hi-Rest and Lo-Rest, two broken halves of the tower of Babylon.
    Sacrificial Rabbit
    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
  • # No REST In Lo-REST
    you've been HAACKED
    Posted @ 3/23/2006 10:08 AM
  • # Hi-REST/Lo-REST Pushback
    Dare Obasanjo aka Carnage4Life
    Posted @ 3/25/2006 9:32 AM
  • # My 2 cents on REST
    Kent Sharkey
    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…
    pwb
    Posted @ 3/27/2006 11:33 AM
    Tim Bray chimed in with something practical. I tend to agree:
    http://www.tbray.org/ongoing/When/200x/2006/03/26/On-REST
Title  
Name  
Url
Comments   
Please enter the code you see below. what's this?
This CAPTCHA image helps deter automated scripts that submit comment spam. In essence, it helps us determine that you are indeed a human instead of script.

 
   
 
© 2004 Pluralsight.
Visual Design by Studio Creativa
Privacy Policy