As I discussed in my last post, the new WCF Http Model includes http processors that you can use to inject cross cutting aspects into an existing service. We can use processors for supporting a versioning schema based on content types as it discussed here by Peter Williams.
Supporting custom media types in a WCF Http Service is a now a piece of cake with the new MediaTypeProcessor. The only thing you need to do is to implement a new processor by deriving your class from the base class MediaTypeProcessor or any existing implementation like XmlProcessor for example.
The implementation I showed below derives from the XmlProcessor implementation and adds support for two new content types (“application/vnd.mycompany.myapp+xml” and “application/vnd.mycompany.myapp-v2+xml”)
That represents one part of the implementation. Now, the resource implementation somehow needs to know which message it needs to return according to the “accept” header sent by the client implementation. The resource implementation can just look for the “accept” header in the request message by passing an “HttpRequestMessage” argument to the operation. However, I decided to go with a different approach so the operation implementation did not get tied to a content type.
The operation receives an argument representing the version that needs to be returned to the client. As you can see, the implementation returns Account or AccountV2 based on that version argument.
AccountV2 adds a list of emails to the account information.
You might be asking how I did to transform the accept header into a version argument. Well, the response is another processor implementation :)
This processor receives the RequestHeaders, looks for the Accept Header in the “OnExecute” method, and returns a version number based on the value found on that header. The version number in this example could be 1 for “application/vnd.mycompany.myapp+xml” or 2 for “application/vnd.mycompany.myapp-v2+xml”.