The WCF WEB HTTP Programming Model allows developers to expose Windows Communication Foundation (WCF) Web services through basic HTTP requests without requiring SOAP. The WCF WEB HTTP Programming Model is built on top of the existing WCF extensibility model. Using this article I’m going to explain how to create a REST enabled WCF Service. I have used a simple Patient Sevice to demonstrate the RESFful WCF Service.
What is REST
REST stands for REpresentational State Transfer. The term representational state transfer was introduced and defined in 2000 by Roy Fielding as a concept in his PhD dissertation . The REST is resource based, a resource can be a person, address, user etc and in a RESTful service we will be doing some operations on the resources. The constraints of REST are based on the same underlying principles that govern the Web. Those principles are,
- User agents interact with resources, and resources are anything that can be named and represented. Each resource can be addressed via a unique Uniform Resource Identifier (URI).
- Interaction with resources (located through their unique URIs) is accomplished using a uniform interface of the HTTP standard verbs (GET, POST, PUT, and DELETE). Also important in the interaction is the declaration of the resource’s media type, which is designated using the HTTP Content-Type header. (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
- Resources are self-descriptive. All the information necessary to process a request on a resource is contained inside the request itself (which allows services to be stateless).
- Resources contain links to other resources (hyper-media).
WCF and REST
WCF is the Microsoft framework for building applications that communicates over a network, regardless of the style or protocol. The WCF Services has the ability to expose REST services using System.ServiceModel.Web assembly. This ServiceModel gives you two attributes, WebGetAttribute and WebInvokeAttribute and a URI template mechanism that enables you to declare the URI and verb to which each method is going to respond.
Read more from CodeProject.com
Global Exception Handling – IServiceBehavior and IErrorHandler
To demonstrate this we need to create an ErrorHandler class by implementing the IErrorHandler and also a ServiceBehaviorAttribute class by impementing a IServiceBehavior. IServiceBehavior allows you to implement a service behaviour attribute which takes a custom error handler parameter which implements IErrorHandler
The IErrorHandler type exposes two methods. HandleError and ProvideFault.
- Use the HandleError method to implement error-related behaviors such as error logging, system notifications, shutting down the application, and so on, and return a value that specifies whether the exception has been handled appropriate.
- ProvideFault enables the creation of a custom FaultException<TDetail> that is returned to to the client from an exception in the course of a service method.
The IServiceBehavior type exposes three methods. AddBindingParameters, ApplyDispatchBehavior and Validate. For this article we are much interested only in ApplyDispatchBehavior method.
- Here AddBindingParameters provides the ability to pass custom data to binding elements to support the contract implementation.
- ApplyDispatchBehavior provides the ability to change run-time property values or insert custom extension objects such as error handlers, message or parameter interceptors, security extensions, and other custom extension objects.
- Use the Validate method to confirm whether the current service can execute properly according to your scenario.
How it works
Whenever an unhandled exception occurs in a service decorated with the service behaviour attribute, two methods on the global error handler are called automatically: ProvideFault which allows you to construct a FaultException (rather than let ServiceModel do it), and HandleError which is intended for logging. The ProvideFault method is called first on the worker thread that is invoking the service call and HandlerError is called asynchronously on a separate thread, so lengthy logging operations don’t block the service request thread from sending a FaultException back to the client immediately.
Read more from CodeProject.com