HOW REST is implemented in WCF
Part-I of the series explored the REST conceptually and this post will explore how REST is implemented in WCF.
For REST implementation in WCF, 2 new attributes namely WebGetAttribute and WebInvokeAttribute are introduced in WCF along with a URI template mechanism that enables you to declare the URI and verb to which each method is going to respond.
The infrastructure comes in the form of a binding (WebHttpBinding) and a behavior (WebHttpBehavior) that provide the correct networking stack for using REST. Also, there is some hosting infrastructure help from a custom Service¬Host (WebServiceHost) and a ServiceHostFactory (WebServiceHostFactory).
How WCF Routes messages
WCF routes network messages to methods on instances of the classes defined as implementations of the service.
Default behavior (Dispatching) for WCF is to do this routing based on the concept of action. For this dispatching to work, an action needs to be present in every message that WCF receives from client. Each unique action is mapped to a particular Action method.
The value of Action is based either on the name of the method in the service implementation (plus the namespace of the service) or a custom value (set via the OperationContractAttribute.Action property).
WCF routing mechanism for REST
When the REST infrastructure is used with WCF, the default dispatcher, as described above is not used. The dispatched in this case makes routing based on the URI of the incoming request and the HTTP verb being used rather than the Action.
This routing is made possible by using WebHttpDispatchOperationSelector class and without it a RESTful endpoint cannot be used.
This dispatcher is configured on each endpoint of the service (where REST is desired) by a behavior named WebHttpBehavior.
WebGetAttribute and WebInvokeAttribute
WebHttpDispatchOperationSelector class needs to know how to map different URIs and verbs to the methods in the service implementation.
To make the class ware about the mapping(s) the WebGetAttribute and WebInvokeAttribute must be added to the methods on WCF ServiceContract.
WebGetAttribute tells the dispatcher that the method should respond to HTTP GET requests.
WebInvokeAttribute is mapped to HTTP POST by default, but the WebInvokeAttribute.Method property can be set to support any of the other HTTP verbs (PUT and DELETE).
By default, the URI is determined by the name of the method (added onto the base URI of the endpoint).
Wait a minute, REST talks about resources that are nouns not verbs, so how come to URI is getting identified as method name?
Not to worry, here comes the real beauty, WCF REST programming model allows customization of URIs for each method by using templates that can be set via the UriTemplate property on WebGetAttribute or WebInvokeAttribute.
UriTemplate and UriTemplateTable
To enable customization of the URI for each method and verb combination, WCF added the ability to define the URI for each resource by using a special template syntax which allows to define, with replaceable tokens, the URI structure that each method in conjunction with the HTTP verb (via the WebGetAttribute or WebInvokeAttribute) would use for representation.
WebHttpBinding and WebHttpBehavior
In WCF, a binding determines how WCF is going to communicate. There is a list of Bindings that can be used for communication.
For a RESTful endpoint, the WebHttpBinding is used.
WebHttpBinding contains only two components: the HTTP transport and the text message encoder.
WebHttpBehavior is the object that causes the URI-plus-verb dispatcher to be used, so the WebHttpBinding and the WebHttpBehavior are almost always used together.
WebServiceHost and WebServiceHostFactory
The WebServiceHost class automatically creates the endpoint and configures it with the WebHttpBinding and WebHttpBehavior, hence avoiding repetition for adding WebHttpBinding and WebHttpBehavior manually for each endpoint.
WebServiceHostFactory, which uses an open WCF extensibility point (using a custom ServiceHostFactory type) in the managed hosting scenario to create a configuration-free experience for many RESTful services.
WebServiceHostFactory creates an instance of the WebServiceHost, and since the WebServiceHost will auto-configure the endpoint using WebHttpBinding and WebHttpBehavior, there doesn't need to be any configuration for this endpoint in the web.config at all.
Note: if the binding needs customization, use the configuration system or build a class that derives from WebServiceHost/WebServiceFactory.
Although I intended to write a sample application in this post itself, however there is lot of information that needs to settle down the brain.
For the time being, let the brain digest this knowledge and part-III will summarize both the parts and the main concentration would be on the Demo app.
Till next we connect….
Happy Learning
Part-I of the series explored the REST conceptually and this post will explore how REST is implemented in WCF.
For REST implementation in WCF, 2 new attributes namely WebGetAttribute and WebInvokeAttribute are introduced in WCF along with a URI template mechanism that enables you to declare the URI and verb to which each method is going to respond.
The infrastructure comes in the form of a binding (WebHttpBinding) and a behavior (WebHttpBehavior) that provide the correct networking stack for using REST. Also, there is some hosting infrastructure help from a custom Service¬Host (WebServiceHost) and a ServiceHostFactory (WebServiceHostFactory).
How WCF Routes messages
WCF routes network messages to methods on instances of the classes defined as implementations of the service.
Default behavior (Dispatching) for WCF is to do this routing based on the concept of action. For this dispatching to work, an action needs to be present in every message that WCF receives from client. Each unique action is mapped to a particular Action method.
The value of Action is based either on the name of the method in the service implementation (plus the namespace of the service) or a custom value (set via the OperationContractAttribute.Action property).
WCF routing mechanism for REST
When the REST infrastructure is used with WCF, the default dispatcher, as described above is not used. The dispatched in this case makes routing based on the URI of the incoming request and the HTTP verb being used rather than the Action.
This routing is made possible by using WebHttpDispatchOperationSelector class and without it a RESTful endpoint cannot be used.
This dispatcher is configured on each endpoint of the service (where REST is desired) by a behavior named WebHttpBehavior.
WebGetAttribute and WebInvokeAttribute
WebHttpDispatchOperationSelector class needs to know how to map different URIs and verbs to the methods in the service implementation.
To make the class ware about the mapping(s) the WebGetAttribute and WebInvokeAttribute must be added to the methods on WCF ServiceContract.
WebGetAttribute tells the dispatcher that the method should respond to HTTP GET requests.
WebInvokeAttribute is mapped to HTTP POST by default, but the WebInvokeAttribute.Method property can be set to support any of the other HTTP verbs (PUT and DELETE).
By default, the URI is determined by the name of the method (added onto the base URI of the endpoint).
Wait a minute, REST talks about resources that are nouns not verbs, so how come to URI is getting identified as method name?
Not to worry, here comes the real beauty, WCF REST programming model allows customization of URIs for each method by using templates that can be set via the UriTemplate property on WebGetAttribute or WebInvokeAttribute.
UriTemplate and UriTemplateTable
To enable customization of the URI for each method and verb combination, WCF added the ability to define the URI for each resource by using a special template syntax which allows to define, with replaceable tokens, the URI structure that each method in conjunction with the HTTP verb (via the WebGetAttribute or WebInvokeAttribute) would use for representation.
WebHttpBinding and WebHttpBehavior
In WCF, a binding determines how WCF is going to communicate. There is a list of Bindings that can be used for communication.
For a RESTful endpoint, the WebHttpBinding is used.
WebHttpBinding contains only two components: the HTTP transport and the text message encoder.
WebHttpBehavior is the object that causes the URI-plus-verb dispatcher to be used, so the WebHttpBinding and the WebHttpBehavior are almost always used together.
WebServiceHost and WebServiceHostFactory
The WebServiceHost class automatically creates the endpoint and configures it with the WebHttpBinding and WebHttpBehavior, hence avoiding repetition for adding WebHttpBinding and WebHttpBehavior manually for each endpoint.
WebServiceHostFactory, which uses an open WCF extensibility point (using a custom ServiceHostFactory type) in the managed hosting scenario to create a configuration-free experience for many RESTful services.
WebServiceHostFactory creates an instance of the WebServiceHost, and since the WebServiceHost will auto-configure the endpoint using WebHttpBinding and WebHttpBehavior, there doesn't need to be any configuration for this endpoint in the web.config at all.
Note: if the binding needs customization, use the configuration system or build a class that derives from WebServiceHost/WebServiceFactory.
Although I intended to write a sample application in this post itself, however there is lot of information that needs to settle down the brain.
For the time being, let the brain digest this knowledge and part-III will summarize both the parts and the main concentration would be on the Demo app.
Till next we connect….
Happy Learning
Comments
Post a Comment