tags:

views:

892

answers:

7

I just worked through a book on WCF and was surprised that it didn't even mention REST at all.

Was REST an afterthought for WCF that was added in .NET 3.5 SP1 and hence not baked in well or is it well integrated?

I assume that Silverlight and XBAPs can consume WCF with no problem or do they have some limitation due to their sandbox environments? I've been reading that some people are having problems getting WCF to play well with XBAP and I would assume there are similar problems with Silverlight.

+3  A: 

John Papa spoke at our local .Net user's group. He demonstrated a Silverlight -> Restful service call. You could get his book and/or download his code.

Search for "Source Code For Data-Driven Services with Silverlight 2" on the above link. I'm not direct linking it because the url might change (he updates the file).

David B
just ordered it, thanks
Edward Tanguay
FYI the scenarios John covers in his book are about WCF ReST, not about ReST itself, or how to interoperate with a ReST architecture. I should know, I reviewed the chapters in his book. Check the Thanks page...
serialseb
+1  A: 

This a personal view but I don't see the RESTful support in 3.5 SP 1 as an after thought. Creation and consumption is possible with WCF while things like ADO.NET Data Services embrace it as a key feature.

Silverlight and XBAPs can consume WCF with no problems. The biggest issue with them is

  • Security. There is significantly higher security placed on them which can cause issues not seen in fully trusted apps. This is meant to protect the user so I don't see that as a bad thing, just something that needs to be worked with.
  • Silverlight is Async ONLY.

My personal expierence is that Silverlight is easier to work with WCF than XBAPs as the security model is better defined than the sillyness of running XBAPs (why not just use click once + WPF and you get the exact same as XBAPs without headaches - I'll get off my soap box now)

Robert MacLean
How do you define REST? Is it based on Roy Fielding's definition?
Ryan Riley
A: 

Everything which has to do with distribution will be baked into WCF, but WCF as a framework will reside. That means, it will reside when it's core concept is strong enough. This core concept is what WCF provides: A framework for implementing new distributed communication protocols. These assets can be shared between projects. WCF is a runtime where these assets can live. Every WCF programmer will know immediately how to integrate new WCF assets. For example: ServiceBus component in Azure is shipped as new assets for WCF. A project which is already WCF enabled can immediately switch to the new ServiceBus. REST is not WCF, but WCF has been extended with REST without breaking it's core concept. Besides that, WCF has lots of other protocols: Streamed, Bidirection, WS-*,.... Silverlight has no WCF integration. It supports HTTP and TCP/Socket communication. Why there is a close relation between Silverlight and WCF? Silverlight is in a phase where it is extended rapidly. It's communication stack, too. Each new way of communication in Silverlight, is also supported by WCF. It is evolving in synergy. By the way, Linq has a core concept for evolution, too.

guerkan
Youre confusing technical plumbing and architectural styles. The idea that you can "just run" your code and create a different archtiecture as a result of config switches cannot be reconciled with reality.
serialseb
+6  A: 

As far as REST on WCF is concerned, I think Tim Ewald said it best

"... I'm not sure I want to build on a layer designed to factor HTTP in on top of a layer that was designed to factor it out."

Darrel Miller
+18  A: 

Many of the constraints to apply to a REST system will be difficult, if not impossible, to implement with WCF REST. The programming model has leaky abstractions (different methods for json / xml), doesn't support multiple media types (only xml and json), relies too much on uri parameters for method selection, etc. And it doesn't integrate with asp.net in any way, aka there's a difference between the service /customer handled by WCF and the /customer that should return html.

Not that you couldn't implement all those yourself, but you'll soon end up with something that replaces nearly everything that WCF Rest has out of the box.

serialseb
Your comments mirror my experience almost exactly. After spending a year doing REST on WCF I have almost completely replaced what the WCF stack was doing for me with HttpListener and about 500 lines of my own code.
Darrel Miller
A: 

Doing REST with WCF prior to 3.5 basically means not doing a lot of stuff that was baked into WCF. But implementing a REST service is very well doable with WCF before 3.5, it just involves more code. You basically have to ignoring SOAPy things, and build your own custom channel stack. (To do this you have to create a CustomBindings and tell the TextMessageEncoder not to use SOAP (by using MessageVersion=None)) The stuff you gain with 3.5 is that all the REST stuff comes implemented out of the box and you have the option to specify a REST interface by using WebHttpBinding. So, in my opinion, the REST implementation fits nicely in the existing WCF stack and is not a hack added to it. But they made it simple to use a slimmed-down, not SOAPy version for REST out of the box in 3.5.

A: 

For completeness, Effective REST Services via .NET: For .NET Framework 3.5 by Kenn Scribner and Scott Seely exists. DNR or HC or DFB spoke to Scott and I bought it for general WCF coverage. I have yet to read it (or even leaf through it) and will report back if/when I do (though I wouldnt be surprised if it I dont even do that before running to OpenRasta).

Ruben Bartelink