RESTing from MEF (or The MEF dealer is at REST)


Side note: I am having serious writer’s block these days….or maybe it’s twitter’s block :-)

Continuing the tradition of overdue posts…….It’s been over a month since i left the MEF team. Before moving on let me say that working on MEF was a fantastic experience! The team is very excited to see all the community interest and adoption we’re seeing with MEF in commercial products, internal applications, as well as OSS projects. Thank you all for your support over these past two years.

Where am I?

I’ve moved over to the WCF team where i am now RESTing :-) My focus is on providing platform support for distributed applications that communicate over HTTP and which conform to a RESTful style. If you are using WCF, then you may be familiar with WCF WEB HTTP which shipped with the .NET Framework and the REST Starter kit which shipped out of band. That’s my team.

Why HTTP and REST.

HTTP is the application layer protocol that the web is built on. Browse to any web page and you immediately see HTTP in action in this case for delivering HTML web pages. HTTP is not limited as a transfer for HTML, it’s much richer. You can use  HTTP for delivering data as well as core application functionality, and you don’t have to use SOAP to do it. Applying the constraints of REST lets you take direct advantage of the capabilities HTTP provides in order to achieve greater scalability, performance and evolveability.

For example if you are using a blog reader to read this post, then it is very likely that you have subscribed to an Atom feed. AtomPub is one popular incarnation of RESTful principles that is primarily used for data feeds such as a blog, a video queue, etc. If you’ve heard our recent announcements about OData, it builds on top of AtomPub to provide a protocol for querying and updating data. Another popular usage of REST services is for building AJAX style applications which communicate with the server using JSON. REST however is not at all limited to these scenarios, as a matter of fact you can apply REST to solve many of the problems that today you are doing through SOAP based services albeit in a different (and many argue simpler) fashion.

It’s not WS-* and that is a good thing

REST doesn’t bring all the bells and whistles of the WS-* protocols, however its power is in its simplicity. That means no SOAP client stack required. For many systems the “power” WS-* brings is unnecessary, and that power is not free, that means it can turn into a tax. That doesn’t mean WS-* in itself is bad…it definitely provides value.

There’s a growing momentum in the community and the enterprise for building RESTful systems and for frameworks which enable that. Take a look at and you’ll see 1500 APIs listed under the REST category. These APIs run the gambit in terms of their application of RESTful principles, but regardless it is clear that companies are looking more and more to expose their systems over HTTP.

Why do we need something new?

One word, Freedom. Freedom to work directly with the protocol and freedom to harness all of it’s richness.

The work we did in WCF 3.5 and 4.0 was a great first step. It allows you to use the traditional WCF service model and tweak it to behave well over HTTP. However, it has it’s limits. WCF was designed to shield the service author from any of the underlying transport details. It was also designed around an RPC style of communication, i.e. a Service operation corresponds to a method. Folks that are exposing services (Resources) over HTTP don’t want those details hidden, in fact they embrace them. HTTP is also not based on classes, types or methods, its based on resources and verbs.

We want WCF to provide a natural experience which allows you to fully embrace HTTP within your development. We want to allow you to develop in a resource-oriented style. To that end we’re looking to extend WCF and introduce a set of client and server APIs completed based on HTTP. Those apis will enable building RESTful systems, or RESTful frameworks to build RESTful systems :-)

What about WCF Data Services?

WCF Data Services is designed to allows developers to expose entity data models using the OData protocol such that they can be queried and updated by OData clients. The work that we are doing with WCF WEB HTTP is to enable both clients to interact with arbitrary resources exposed over HTTP, as well as to enable exposing resources over HTTP in an arbitrary manner. It’s basically the “have it your own way” of HTTP.

We’re not the first to the party

Look across the .NET OSS community alone and you will see there’s a healthy ecosystem budding of frameworks like OpenRasta, RestSharp, Hammock. Glance into the Java, Ruby and Python worlds and you will see the same with frameworks like Restful Rails, Sinatra, RESTlet, RESTfulie (also in C#), and Jersey to name a few. Oh and don’t forget JQuery and ExtJS :-) All this existing innovation is a great thing! It means we have a lot of existing mindshare we can pull from to ensure that whatever we deliver plays by the rules.

Two key goals: Simplicity and Testability.

  • Less is more. We want to do less but make sure whatever we do is really easy to use (and really useful).
  • Simple to test. Not technically feasible to test after you do a lot of work :-)

We want your help

We’re not going about this alone:

  • We want you to help us get there.
  • We want you to validate that what we’re building meets the needs and that we’re playing by the industry rules.
  • We want you to tell us that what we’re building is right, rather than us telling you it will make your life better.

We’re still in the early phases of determining exactly what that means, but if you followed the way MEF was developed you can imagine 😉

You don’t have to be using .NET or Microsoft technologies to help

If you are passionate in this space we’d welcome your involvement. I look forward to making this new journey with you.

This entry was posted in REST. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Glenn Block

    Hi Carl, can’t speak to the timeline yet, but we are working on getting to Codeplex soon and hopefully under a license that wil let you run with it sooner rather than later. It won’t be years though.

    This will not be left in preview status. This work is part of the platform. The reason I joined the team is primarily to focus on this.

    I hear you. There are several things we are doing which we think can improve that.

    1. We intend to develop this in a very open fashion involving the community. This is why we are looking to get to codeplex.

    2. We are involving several leaders in the REST community to work with us as we develop and make sure that we are delivering something authentic.

    3. We are  making signficant investments in WCF and streamlining to have a lighter, better and more testable HTTP experience.

    We’re also thinking about being more intentional about a simplified config story, supporting conventions, and simple extensibility points.

    In terms of ASP.NET MVC, we have looked at it. We have certainly done and will continue to do more work to integrate better with ASP.NET, hence the routing work we did in 4.0. Self-hosting directly on top of HTTP without ASP.NET is a scenario though that is important to our customers and which is lighter.

    I’ll be posting more on what this all means hopefully in the next few weeks.



  • Carl Taswell

    Thanks for answer. How about the timeline? Weeks, months, years?

    And when released, will it be like the REST Starter Kits? Left in “preview” status, and then never advanced to an official release?

    Sorry, but WCF for RESTful apps has a “bad image” problem to overcome, at least for me, given the past history of lack of confidence-building support for REST in WCF.

    Also, there are advocates for using ASP.NET MVC for building RESTful apps such as Scribner and Seely in their book “Effective REST Services via .NET”. And ASP.NET MVC does not have the “image problem” that using WCF for REST has.

    So can you give us some idea of what this new WCF based project will offer that could persuade us to keep an open mind? If not, then I’ll probably just start building on top of ASP.NET MVC…..

  • Glenn Block

    The current plan is it will be on top of WCF. However, we are making invesments to make it a much lighter HTTP stack.

  • Carl Taswell

    I asked this question on Ron Jacobs related blog post on REST, and I note that Henning Anderssen asked the same question here as well. So one more time till we get an answer: Will this new Microsoft framework for REST be built on top of WCF, on top of MVC, or completely independent of either?

  • Bnaya Eshet

    The biggest disadvantage of the current REST implementation is the luck of solid security modern model (not SSL),
    If you will manage to supply a simple reliable security model that can handle
    1. Authentication
    2. Authorization (I would like to see a claim base model)
    3. Cryptography (message base encryption) I will consider to use the model for
    for real life application.
    Another goal which I expect is to let me expose my contract through traditional WCF and REST without having to change the contract or the service implementation (i.e. to keep the REST layer at the hosting level)

  • Henning Anderssen

    Will it be an “addon” to WCF or will it be completely free standing?

  • Glenn Block

    Thanks Henning

    Many of the points on that list are explicit goals for what we are doing. We’ve been talking to many folks in the OSS community to both gain inspiration and to bring folks to participate in the work we are doing. We also are aiming

    Personally I am a big fan of OSS and have many friends who run OSS projects so I definitely want to work with them and not reinvent the wheel.

    The why not just support OSS is a different and much bigger question and one I am sure I can give a satisfactory answer :-) I can say that we’ve been hearing more and more folks asking us for a better in-the-box solution for building RESTful style systems. We’ve made progress on this with our .NET 3.5 and 4.0 work but we believe we can go much further, which is why we are doing this work.

    I see the work we are doing as an potential enabler for OSS. Meaning if you look at the frameworks that are out there, they are all implementing their own HTTP stacks. If we provide a good HTTP stack with the right hooks, they can build on top.

  • Henning Anderssen

    I realized that I didn’t provide any helpful points.

    Here’s my take on it:

    1. Find inspiration from other OSS project, not necessarily REST projects.
    2. Make heavy use of convention over configuration, and allow your users to specify their own conventions if need be.
    3. Code first development. If you make a designer you’ve done it wrong.
    4. It should be able to operate with other frameworks, such as OAuth, etc.
    5. Allow for extensibility.
    6. Abide by the rules of HTTP. Use the same naming, i.e methods not verbs
    7. Probably no need to create a schema. If you make it something in the ballpark of OData, I will never ever use it. It should work with POCO classes.
    8. NO web.config/app.config.
    9. Support multiple dataformats, such as XML, JSON, etc, and make it easy to switch between the different formats. Let the user of the REST service choose which format they want.
    10. No attributes should be necessary to serialize the classes, so NO DataContract attribute.

    This is a few of my opinions that would make a good framework :)

  • Henning Anderssen

    Hope I won’t sound negative when I say this, but why another framework when there is so many already?

    Couldn’t you pick one existing framework and help it out, either with developers or funding? It seems like Microsoft has to compete with just about every OSS framework that exist. Especially if you can’t bring anything new to the table, why bother?

    A bit off topic, but EF is years behind NHibernate. The story goes on with several other frameworks. I’d rather see you back some existing framework instead.

    Nitpick: Apparently it (post, get, put, etc) is called methods, not verbs

  • Glenn Block


    Thanks for lall your help thus far and for the vote of confidence. I am looking for to chatting with you more in London in a few weeks!

  • Wonsil

    While HTTPS prevents snooping of data, I think Zubair is right that you need something to prevent hijacking of transactions through impersonation.

  • Jan Algermissen


    kudos for the commitment to openness – this looks promising.


  • Jan Algermissen

    Zubair, the key thing about HTTP is that authentication and on the wire security is *orthogonal*. If you do not like HTTP Basic or HTTP Digest or OAuth or if you want to add per-message encryption or digital signatures it is all yours to add it in without breaking what you already have.

  • Anoop (@amazedsaint)

    I’m pretty sure that you wrote this post because you don’t need any more twitter attacks from me about MEF, lol.

    Best regards with your new ventures.

  • Glenn Block

    Hi Zubair

    The most common way to secure REST services is with HTTPS. Depending on the need that may not be sufficient. As you mentioned OAuth is one protocol which addresses part of the problem. I am sure others will emmerge. It will be interesting to watch :-)

    As a side note I know that many folks use the whether or not HTTPs is sufficient to decide whether or not they expose over REST or not.

  • Zubair


    Nice article,but I dont see many ways to secure RESTful services except OAuth,corporates dont like their data out in the wild