Is the WCF REST Starter Kit dead in the water?

问题:

We are looking at switching from using WCF for our service layer in applications to REST.

So far we are assuming that the way to do this is to use the WCF REST Starter Kit. However this is still in Preview 2 and hasn't been updated since March 2009.

Is this project dead in the water?

If so, what alternatives do we have for creating .NET-based REST services? (Some are suggesting using ASP.NET MVC, which we're already using for our UI layer)

Edit

It looks like now, the WCF REST Starter Kit is indeed dead. The ASP.NET Web API is the recommended alternative.

回答1:

WCF provides support for REST-style services since the release of .Net Framework 3.5, and you can start building REST services on WCF today.

The WCF REST Starter Kit is intended as a vehicle for the team to get feedback from the community on new feature ideas around REST in WCF. We are actively working on incorporating developers' favorite starter kit features in the .Net Framework - for example you can use the help page feature in the recently released .Net 4 Beta 1 release. As we get feedback on starter kit features we consider them for inclusion in the framework, which you can use in production.

Regarding the comments that the starter kit is "dead in the water", I can assure you it's quite to the contrary. We aim for a 4-month development cycle on new versions of the starter kit, as we have stated on the starter kit homepage. We have resources dedicated to supporting the starter kit and working on future versions.

回答2:

After spending a tremendous amount of time playing with different .net rest frameworks I've come to a conclusion. Using asp.net mvc is by far the easiest and most transparent way to handle restful services. There is a whole lot less confusing configuration.

Asp.net MVC

By it's very nature, asp.net mvc fits the restful service methodology. Rather than taking a complicated soap-driven framework and "adapting" it to the restful protocol, asp.net mvc embraces the web programming paradigm at it's core. It's much more transparent and easy to debug. Using the asp.net routing framework, iis requests are wired up to controller classes. Returning any type of content is a breeze. Getting setup is much easier because of the Convention over Configuration philosophy. It just works. 'Nuff said.

Here is the list of projects that I played with while trying to get wcf to work well with rest. I spent days learning about the different approaches. In the end, there were things I liked about each one, but there was nothing that took care of all of our needs. Mvc wins.

WCF Rest Projects

---

WCF Rest Contrib - wcfrestcontrib.codeplex.com

This project has some really helpful features like zero configuration, error handling (for returning proper web response codes), and web authentication.

It requires you to change the service factory class which creates your wcf service. This means that it cannot play well with other libraries that require you to use their factory.

WCF Rest Starter Kit - code.msdn.microsoft.com/wcfrestlabs/

This is really just a "learning tool" and lab to show how rest could be implemented in wcf. It does not look like it's being updated any more. I think asp.net mvc and wcf 4.0 has taken the wind out of it's sales. It does have some good classes which did end up getting incorporated into wcf 4.0 (Help feature).

Documentation Tools

---

WCF Rest AutoDocs - autodocs.codeplex.com

Generates really cool, easy to use documentation based on attributes and a new endpoint behavior adapter class.

I hit a big snare with this. When I added it to WCF suddenly posts no longer worked. I kept getting an endpoint not found error. I eventually gave up and stopped using the library. Did not work well with other libraries.

WCF Doc - wcfdoc.codeplex.com

Generates documentation for soap and rest based services. You can create your own xslts and generate cool looking documentation based on your company's branding. I'm currently integrating this into our build process.

回答3:

It depends on your scenarios, but you'll find that WCF REST gets in your way quite a bit to enable certain scenarios.

The starter kit starts to fix some of those issues, others will be fixed with the next version, but if you want things link creation, content type negotiation and custom media types, you're going to be spending a lot of time making it work.

There are other frameworks out there that solve the same problem in a more straightforward fashion, I suggest you have a look at OpenRasta and Snooze, or even MVC.

回答4:

We used WCF to implement a RESTFUL api, where we could post and receive data using XML, JSON and ProtoBuf. Same thing with GET.

However, once we looked at ASP.NET MVC we dumped WCF and are now using MVC to do the same thing with much more transparent code. There is some nice articles on google on how to do this. Our primary need was to give clients the option to serialize request and receive responses to XML, JSON, or Protobuf.

I would say WCF is dead to us. Long live MVC

回答5:

Another possibility is that this functionality will be part of .NET 4.0 and Visual Studio 2010. I suggest you download the beta and find out.

回答6:

I don't think it's going anywhere. It took 4 months to get from Preview 1 to Preview 2 and it's only been 3 months since then. Far from official, but this article names it as a highlight of Framework 4 - Beta 1. There was a PDC session on it as well. Too many organizations are using REST for their services to not have support in WCF.

回答7:

So far we are assuming that the way to do this is to use the WCF REST Starter Kit. However this is still in Preview 2 and hasn't been updated since March 2009.

You can build REST apps with WCF, without the Starter Kit. WCF that shipped in .NET 3.5 included good REST capability and tools. It includes the URI Template mapping, the WebGet attribute, and more.

The starter kit is sample code, add-on utility classes, videos, and other add-on stuff that helps illustrate how to do REST in WCF. You don't need the starter kit to do REST in WCF.

You do not need to wait for the starter kit to be "completed" in order to do REST in WCF. If there is stuff in there that you like, like the Http Request builder, then use it. It's open source, you can use in in your project. If you don't like it, don't use it.

回答8:

If your looking for some additional features (Like content type & accept header based de/serialization, per operation authentication, etc) check out the WCF REST Contrib project:

http://wcfrestcontrib.codeplex.com/

It is based on the 3.5 SP1 WCF REST API and offers some functionality not found in the RSK.

回答9:

I am using WCF Rest Contrib only because I needed support for x-www-form-urlencoded format being sent to us from a third-party developed iPad application. Plus, I need support for custom username validation, which is likewise not supported out of the box with WCF 4 REST services.

Unfortunately, the downside was I lost the ability to auto generate help pages, which does not appear to be supported in the WCF Rest Contrib library.

Losing the help pages has turned out to be a real PITA, but I don't see any other option insofar as the requirements above are not negotiable.

I am hoping that, with the explosion of mobile devices using REST, Microsoft will take implementing an industrial strength version in WCF more seriously. As it stands, I was a little dissapointing in WCF 4... I was hoping for something closer to WCF Rest Contrib.

(BTW, the service implementation library ALSO supports a SOAP WS deployment for classic non-mobile clients, which is simpler to implement where WSDL contracts can be used to generate the proxy).

回答10:

We were building an app to consume our existing services. We also had a requirement to implement RESTful services but our main goal was to reuse/centralise our already existing WCF services, achieving reusability.

We then tried out the Web API and found it quite straight forward. It also provided us an additional layer to our architecture that we could also control.

We had performance concerns at first but so far, those have been quite minimal.

So, if you do not mind adding an additional layer on your WCF services, let it exist as a Web API layer, otherwise HttpClient is equally solid as an option.