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
Whenever we write a program we should expect the unexpected and add appropriate code to handle those exceptions.When we write a windows based application we use try/catch blocks in our methods to catch exceptions, and also we show a user friendly message in UI.
But when we work with WCF Service, It is not that much straight forward, So
- How do we handle exceptions in WCF Service?
- How to propagate a user-friendly error message to the client, who consumes the WCF Service?
- How to send business rule validation messages to WCF client?
Handling exceptions in WCF Service is different than usual exceptions in .NET. As the WCF clients may not be based on .NET Technologies we cannot utilize the .NET Exception object to exchange exception details over the wire. For this purpose we should have a generic way to pass exception details to all type of clients, who consumes WCF Service.
For this reason we have SOAP faults, SOAP faults are the way to propagate the exceptions from the service to the client application. .Net has FaultException<T> generic class which can raise SoapFault exception. Service should throw FaultException<T> instead of usual CLR Exception object. T can be any type which can be serialized.
Read more form CodeProject.com