mca blog

i read this post this evening with mixed emotion. it's good to see folks talking about how MSFT is doing more w/ HTTP and REST. it's disappointing to see folks glossing over fundamental problems MSFTis having 'closing the deal' in this very important area. to quote from Jon's blog post: "In case you’re unfamiliar with the theatrical genre I call PDC performance art, I should briefly explain."

each PDC, Don Box and Chris Anderson do a keynote 'bit' where they 'build applications' using the very latest MSFT technology 'off the top of their heads.' in reality, Don and Chris take the time to plan out an excellent choreography that renders the freshest beta bits as fluid stream-of-conciousness-coding. the kind of experience all code-jockeys dream of; what we all imagine pure geek-genius to embody. and they do it with all the humor and timing of stage veterans - which they are. it's the highlight of most attendee's PDC memories.

however, as has already been explained, it's "PDC performance art."

no http auth

for example, this year Don and Chris used MSFT technology to write code to reach and explore most of the new Azure services. and they did it without writing a single bit of SOAP code. this time, it was all about 'pure HTTP.' very REST-ful, too. until they got to the part about authentication. then it was back to using custom token-based authentication. even more inventive, the authentication pattern changed each time they changed the service they were attempting to access. and *none* of the authentication models used HTTP BASIC or DIGEST Auth. so much for REST-ful services.

no content negotiation

and, while Don and Chris did an excellent job of showing how to use the standard REST method collection (GET, POST, PUT, DELETE), they glossed over the serialization story. sure, their example used Atom as the format. they *had* to use it. the MSFT code classes require you pre-set the representation ahead of time. no use of MIME-type to determine the representation; no content-negotiation with the client. nope. use Atom, JSON, or XML. decide before you compile. knock out another of the REST pillars.

limited HTTP method support

and finally, even though Don and Chris were able to show how to use the standard REST method stack, key part of MSFT's new technologies fail in this area. more than one talk this year covered using WCF w/ REST. however, out-of-the-box implementations use only HTTP GET and POST. you need to additional coding to render PUT and DELETE properly (i didn't see any examples of HEAD or OPTION in the talks). the same is true for their new .NET Workflow Service. it has a new workflow action HttpSend that only supports - wait for it - GET and POST. and, to top it all off, the latest version of MSFT's RIA client, Silverlight is limited to supporting only two HTTP methods. i bet you can guess which ones, right?

it's 1999 all over again

don't get me wrong, i think it's great that MSFT is committing resources to building up the HTTP stack support in their developer tools. but *why* do such a spotty job with it? why support less than one half of the HTTP methods? why *not* bake HTTP Auth support into all the platforms? why hard-code serialization formats into the compiled code? because it's easier? because it's not important? because you forgot?

so we are no longer selling SOAP on stage - that's fine. but do we have to wind the clock back to 1999 - the year Don Box signed on as one of the authors of the SOAP spec - when supporting HTTP?

i use, support, and promote MSFT developer tools everyday. i program using the REST constraint model quite a bit. doing both is not easy. and, frankly, after spending four days at PDC2008, i don't see much evidence of it getting easier any time soon.

bummer.