WCF3.5+StarterKit, WCF4 REST, MVC.NET, Web API

Topics: Web Api
Nov 9, 2010 at 10:35 AM

Hi Team,

Given a RESTful API requirement, i've researched WCF3.5+StarterKit, WCF4 REST, MVC.NET for several criteria, some of which includes

  • auto detection of mimetype
  • api-key, security
  • error handling & representation
  • etagging and caching
  • routing
  • configuration and autodocumentation
  • restfulness

Generally i think those are pretty common. In any case, i've eliminated WCF3.5+StarterKit using MvcContrib since the MvcContrib main contributor seems to stop and in any case WCF4 seemed like a continuation of that.

Coming from a strong Rails and ASP.NET MVC background -- in a very close match, I've eliminated MVC.NET because of the extra baggage that it brings to the table, when looking at it from a service's point of view, in other words the programming model doesn't explicitly fit a service per-se.

Kicking off with WCF4 REST, i found several things that existed in MVCContrib to be out of the box which were excellent, and several not (such as nested resources, amogst direction).

Then i discovered Web API which seems like the best of *all* worlds and got me very excited. It seems (From reading the forum), that you are giving it some more of the MVC.NET oomph and going more into that kind of programming model (processors like filters -- which are like rails filters etc.)

Finally the question:

To someone who needs RESTFul API today, and preferably the notion of Web API, since you guys see the entire strategic roadmap, what's the (more) correct move?

Nov 12, 2010 at 4:25 PM

I'd take a look at OpenRasta if your looking to create a RESTful API (http://trac.caffeine-it.com/openrasta).

Coordinator
Nov 12, 2010 at 8:53 PM

Thanks Dotan for the list. I've added comments below.

  • Conneg (which is what I think you mean on mime type) is supported now. You can created media type mappings and we apply conneg based on accept headers.
  • API key support will be there, meaning it will be easy to plug in api keys.
  • You can represent anything you would like with the new model. We have media type processors as an extension point which can be easily authored. These processors participate in conneg today. If you look in the ContactManager sample for example it supports several media types including representation as an image.
  • ETags will be possible in the new model. Our current thinking is not to provide a specific ETag implementation however thorugh our design you will be able to plug in handling for ETags on the request / response.
  • Integration with ASP.NET routes is supported today. However we are planning to do deeper integration. What do you want to see?
  • Configuration- We are looking to add code-based config support as well as support for conventions. What specifically are you looking for?
  • We're not actually looking to build a RESTful API. We are looking to build out a strong HTTP platform that enables REST (whcih is an architectural style applied with HTTP) on top. We want to make sure we're not blocking REST which is why we have folks like Sebastian Lambla, Ian Robinson, Darrel Miller etc on our advisory board as they build RESTful solutions and are ensure our new stuff is up to the task.

In terms of the question of should you use us or MVC. I'd say first, if MVC works for you and you want to use it, then use it. If however you care more about exposing more rich RESTful systems that support things like rich representations, hypermedia, etags, etc then I think you'll find our new Web APIs are more built specifically for those scenarios. Also if you want more support for hosting such as on IIS directly or self-hosted, that's another thing we offer.

Thanks!

Glenn

 

Glenn

Nov 19, 2010 at 12:42 PM
Edited Nov 19, 2010 at 12:44 PM

 

Hi Glenn,

Thanks for your response,

sorry for the really really late response. Everything that is happening around REST and .Net ignited a fun project for me which took most of my time, hopefully I'll be able to upload the code soon.

 

 

  • Conneg (which is what I think you mean on mime type) is supported now. You can created media type mappings and we apply conneg based on accept headers.
    Yep - i've seen it and its excellent
  • API key support will be there, meaning it will be easy to plug in api keys.
    Good news, i think its great thinking from your part. people should not re-implement the same thing over and over again, i know i have, at least in .net, ruby, and java.
  • You can represent anything you would like with the new model. We have media type processors as an extension point which can be easily authored. These processors participate in conneg today. If you look in the ContactManager sample for example it supports several media types including representation as an image.
    Also - excellent, I think following concepts that exist in MVC is really important. it is a very natural model, and its good that things are being inspired by it.
  • ETags will be possible in the new model. Our current thinking is not to provide a specific ETag implementation however thorugh our design you will be able to plug in handling for ETags on the request / response.
    Ofcourse, my thoughts on this were twofold
    - through metaprogramming or providing a known interface (say, IVersionable), or attribute
    - declaratively - because sometimes i would like to control where if-none-match halts the processing of the request, for example.
    ofcourse etagging needs to include both the etag encoding and the if-none-match logic as a single package imho.
  • Integration with ASP.NET routes is supported today. However we are planning to do deeper integration. What do you want to see?
    Personally i like the concept of having much of the routing handled in a central place like global.asax. however i do know that some people think that routes should be as
    close to the code that handle those.
    I guess offering both ways and letting the devs pick their way would be good.
  • Configuration- We are looking to add code-based config support as well as support for conventions. What specifically are you looking for?
    I think you're spot-on. Code based and convention based is good.
  • We're not actually looking to build a RESTful API. We are looking to build out a strong HTTP platform that enables REST (whcih is an architectural style applied with HTTP) on top. We want to make sure we're not blocking REST which is why we have folks like Sebastian Lambla, Ian Robinson, Darrel Miller etc on our advisory board as they build RESTful solutions and are ensure our new stuff is up to the task.
    Great. one thing that worries me tough, is the extra plumbing in WCF that is _not_ used for that end. perhaps some way to cut out all of those would benefit performance.

All in all, i think many people need this _yesterday_, i think your work is very important that i cannot stress it enough.

Its so important that personally i cannot wait for it to complete and i'm going ahead and implementing a REST framework which i'll opensource later. I'll switch to WebAPI as soon as its production ready.

 

Thanks guys!

Coordinator
Nov 22, 2010 at 7:45 PM

Hi dotan

In terms of the extra plumbing. I think you will find with the new work that it is minimal. Our goal is to greatly reduce both conceptual and API overhead so other than the messaging stack (which we are using) I would say there's very little "additional" overhead.

Cheers

Glenn