What is the best way to implement a RESTful architecture in .NET today? [closed]

Question

Before you mention it I am aware that this question has been asked before but not since the launch of WCF4!

So, after a lot of reading I've decided that a RESTful architecture is the way forward to begin a data providing API. Considering the release WCF 4, ASP.NET MVC 2 and WCF REST starter kit, what is the best way to begin implementing a RESTful architecture NOW?

Me: I am very familiar with ASP.NET MVC so I'd feel quite comfortable there. My knowledge of WCF, however, is lacking.

So WCF4 or ASP.NET MVC? (or something else like the wcf rest starter kit)? Specifically I'm looking for:

• Ease of implementation
• I know ASP.NET MVC, not WCF. Is WCF worth the learning curve?
• Is WCF4 overkill for REST or will ASP.NET MVC falls short at some point?

Answer 1

I've actually implemented or am currently using all 3 of the posted options so I'll give my take. Now that you've clarified what your looking for a little its easier to answer.

OData

OData is great for internal applications when:

1. You are both the server and the client.
2. You are using Entity Framework.
3. You do not use inheritance in your models and are not expecting to query sub-collections.

Odata is awesome because you can use IQueryable on the client side. This comes with some limitations though. The two off the top of my head include that you working with inherited models is a little awkward and you can't do nested collections.

There is also an issue with not really knowing what the supported LINQ capabilities are.

I'd recommend OData is you absolutely need a service layer and only expect to do simple CRUD operations with them. The main problem with every OData problem results in a hard wall you just can't get around sometimes. The client consumer code is really the best part and if you aren't using C# to consume its probably not worth it.

Also without using EFs auto metadata support you'll be writing just the same amount of code to conform to a schema your consumers may or may not enjoy writing against. While there is a Rails wrapper for OData all of this is relatively new. I don't see OData in the wild yet besides really big MS partners.

OData authentication and filtering is also pretty bare bones ATM. You'll be writing a lot of permission related code by yourself if you need to limit data. If you ever want SELECT * FROM TABLE to be limited by permissions be prepared to write some awkward code.

MVC 2

MVC is pretty good for making a RESTful service. You have verb support and return JSONResult is as easy at it can be. The only potential downside is your coding a lot of the error handling yourself and all of your view models should inherit from a base class that shows status codes and error messages.

You also may want to tweak the view engine a little depending on how fancy or convention driven you want your message replies to be. The HUGE benefit to MVC is its very extensible and you can do almost whatever you want. I'm big into combining forms/ajax calls/and rest services into the same controller action. Implement once, get three flavors of the same operation. It would be hard to make MVC fall short because it can be twisted to do almost anything you'd need.

A big benefit to an MVC service is you can sneak a little admin UI in a the application that gets deployed along with the service. Very handy to not have two sites to deploy.

WCF REST

So I'm only using WCF rest in a very limited capacity and it seems... ok... I've used WCF for 3 years and I'm always unhappy with how frustratingly complex it is to extend it. Just like ODATA you'll run into sealed classes and unextensible caverns of functionality pretty quick if you go off the beaten path. This is in direct contrast to MVC's amount of extensibility.

The other problem is your building on top of WCF and all the insanity that goes along with it. I've always said it requires a PhD to use WCF effectively. Rick Strahl had a good article about the pain points of WCF REST. Not sure if things have changed but its worth a read.

WCF REST looks really promising and I'm using it right now I just don't know enough about it to recommend.

Main Points

1. If you don't know your consumers then I'd assume you don't know your API. Don't build a service until you have a use case and and can code against it.

2. MVC is the most extensible and if you are familiar with how things work under the covers you'll probably be better off than implementing a hard to extend MS thing like OData and WCF.

3. All of the "big boys" like Facebook, Amazon, PayPal, Ebay have APIs that don't really conform to any known pattern or schema like OData. Your REST service is really what you make of it. This relates to #1. Concentrate on making it easy for a consumer to work with first.

Answer 2

You should check out OpenRasta. It's a resource-centric framework explicitly designed for implementing RESTful architectures in .NET, and features strong support for things like HTTP content negotiation and digest authentication.

OpenRasta's approach is that instead of implementing your API in terms of verbs (actions), your API should be defined in terms of resources (which will typically map closely onto your API entity model) and codecs, which provide decoupled serialization/representation of those resources as XML, JSON, HTML or any other content format your API needs to support.

It's open source, written entirely in .NET, includes built-in support for IoC and dependency injection (that's how lots of it's wired together internally), and distributed under the MIT license.

Version 2.0 has been stable for a while now, and is being used in production at several places - most notably Huddle.

In my opinion, OpenRasta's strong focus on resources means it's much closer to Roy Fielding's original vision for RESTful architecture than many of the "multi-purpose" web/HTTP frameworks, including WCF and ASP.NET MVC.