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

 

Note: Reposted from post at blogs.msdn.com/gblock on 6/30/2010

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
  August 24, 2010
  I didn't see your original post, but I am excited to hear there is some RESTful passion in the WCF group.  I've been bending WCF to experiment with RESTful transactions for a few years now and have ridden the WCF coaster as it has taken baby steps towards supporting SOAPless POX over HTTP and intelligent URI.  I can't say I've loved every minute, but still have faith in the future of the framework with REST.  Please continue to share information regarding how the community can help.

• Anonymous
  August 25, 2010
  Thanks Chad We are definitely serious about HTTP and REST. In terms of sharing, we're planning to get to Codeplex real soon :-)

• Anonymous
  September 14, 2010
  Hey Glenn, I hope you can bring the types of advancements to the WCF/REST stack as you did MEF!  As a Silverlight developer using MEF, I really want to use OData instead of RIA Services.  So I would like to take advantage of the SL toolkit controls (DataGrid, DataPager, DataForm) but not have to roll my own IPagedCollectionView, etc.  So something like this blogs.msdn.com/.../implementing-server-side-sorting-paging-for-odata-feeds-in-silverlight-controls-datagrid-datapager-dataform.aspx that is MVVM friendly.  OData + Toolkit Controls + MVVM = Much Love...

• Anonymous
  September 22, 2010
  Why there is no more release to the WCF Rest kit on Code-Plex..Why not bridge the gap between WCFWEbHttp and DataSvc?

• Anonymous
  November 12, 2010
  Shreeman, in .NET 4.0 we incorporate several pieces of RSK in the framework. The work we are doing now is conitnuing on that path (such as including HttpClient) and going much further. It officially replaces the starter kit.