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 programmableweb.com 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.

Comments

• Anonymous
  July 02, 2010
  Very exciting, Glenn! I hope we have a chance to get hands-on with this soon =)

• Anonymous
  July 04, 2010
  We succeeded in implementing the Lokad Forecasting API on REST on top of Windows Azure, WCF and .NET 3.5 (http://api.lokad.com/) but it was neither easy nor simple. We did struggle on tons of issues: POX formatter, ad-hoc Basic Auth implementation, WCF not distinguishing between HTTP verbs, getting rid of pesky .svc extensions, encountering half a dozen of capacity limitations (graph serialization limits, request processing time or size, ...), got burned by the 260 chars limitations in URLs, smart messages when facing of half-broken requests. I hope that in the future we won't have to struggle that much for such a simplistic API. I am really looking forward your work.

• Anonymous
  July 04, 2010
  Hi Joannes Thanks for the feedback and glad to know that we are doing now is useful. I would love to chat more with you about your scenarios/emails. Shoot me an email via the contact link, Glenn

• Anonymous
  July 04, 2010
  Nick, thanks man. I hope so too! ;-)