Contents tagged with REST
-
Open Source alternatives in .NET for building RESTful services
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, -
Using the WCF OAuth channel with an ADO.NET service
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.
-
OAuth channel for WCF RESTful services
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.
-
Routing to the right workflow service instance through URI templates (REST workflows part III)
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.
-
Conditional Puts in REST
Conditional puts is a technique generally used in a REST architecture to inform clients about possible conflicts when multiple updates are performed simultaneously over the same resource version. It basically works as fist-write / first-win approach, a client can only commit an operation only if the underline resource has not changed in the meanwhile, otherwise it may receive a http conflict error.
-
Adding documentation to WCF Restful services with the REST Starter Kit
Automatic documentation is another cool feature introduced in the WCF REST Starter kit. While documentation is an important aspect in the development process, unfortunately there is not an standard mode or guidance yet about how this should be done for REST services. This new feature comes to help a little in this aspect of the process.
-
Using SqlCache dependencies with the new WCF WebCache attribute (REST Starter KIT)
Let's begin from a hypothetical example that we want to publish a simple product catalog as an ATOM feed. The product table schema in our database was initially designed as follows,
-
REST and Workflow services play well together - Part II
In my previous post "REST and Workflow services play well together", I mentioned that Http Cookies were one of the built-in mechanisms for transferring the workflow context across calls between the client and the service. While cookies work well for http services, from my point of view, simple Http Headers naturally fit better in a REST architecture. As consequence, I decided to extend the WCF channel stack to support a new a custom channel (Or custom binding) for transferring the workflow context as a http header.
-
REST and Workflow services play well together
REST is not just about CRUD interfaces for your services, a complete long-running workflow can be modeled through the basic verbs as well. As my friend Jesus mentioned, the article "How to get a cup of coffee" represents an excellent source about this topic.
-
Conditional gets in REST
According to the Http specification, any Http GET request should be idempotent and safe. In this context, these principles have the following meaning: