Pablo M. Cibraro (aka Cibrax)

Some weeks ago, I discussed how important "Conditional Get" can be for some scenarios, specially when we want to make a better use of the network traffic.

One of the missing features in the WCF web model is the ability to have a single operation definition and switch the content type for the response according to some runtime setting (Which could be the Accept or Content-Type request header for instance).

It's pretty interesting to see how useful workflow services can be sometimes, specially for business applications that require orchestrating several back-end services calls.

A durable service in WCF is by a definition a service that can persist all its internal state across calls in some durable storage. For every operation, the service state is retrieved from the storage, the operation is executed and finally the state is persisted again in the storage. Therefore, there is not need to keep the service instance idle in memory while waiting for client calls. It is equivalent to a long run session, which make this feature something ideal for long-running processes like workflows (In fact, workflow services are mount on top of this feature),

Usually all my posts about REST are about WCF or mention this technology in some parts. Today, I decided to take a different approach and discuss some of the projects available today for building REST services,  Resourceful and Dream framework (Both available for mono as well).
It is worth mentioning however that the WCF team has made an excellent work introducing the new Web Model in .NET 3.5, it has definitively helped a lot to adopt this kind of service in the .NET platform. In my opinion, there are still some aspects in WCF that could be improved,

As I promised in my previous post "OAuth Channel for WCF RESTful services", it is now time to show this new channel in action with a real service. To make this sample more interesting, I decided to base this implementation on an ADO.NET service that provides information about contacts.

While OpenID and WS-Federation focus on delegating user identity (or a collection of identity claims), OAuth was designed to address a different and complementary scenario, the delegation of user authorization. In few words, OAuth allows a client application to obtain user consent (as access tokens) for executing operations over private resources on his behalf.

Continuing from my previous posts "REST and Workflow services play well together I" and "REST and Workflow services play well together II", in which I created a new binding to send the workflow context as an http header, I've applied some modifications to that sample to support also routing through URI templates. This is very helpful for scenarios where client applications are not necessarily aware of the existence of a workflow services on the other end, so the context information is reconstructed from the resource URI using Uri templates.