Can WebInvoke attributes be replaced by binding configurations

Question

In order to get a WCF service working with JQuery I have added a WebInvoke attribute on the operation contract to control the JSON serialisation as follows:

[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]

Is there a way to control this serialisation via the service bindings in the config instead as it limits this service from providing different serialisations to different endpoints.

Answer 1

I have a different solution, which works at the opposite end from @Marc Gravell's: instead of duplicating the contract, derive 2 different classes from the service implementation. These are just type aliases; they are necessary because the WCF activation system (as least on IIS) will not allow you to activate the same service type at different URLS (I'm not sure why Gravell's solution didn't run into this problem - the error that I'm getting is "A registration already exists for URI..." when I try to activate the same service class at different URLs on the same site). Note that this is only a problem if you want to run the same service with pox and json simultaneously. If all you want is to control the response format, you don't need this workaround.

The key concept behind my solution is to use 2 different URIs for the same service, then use an endpoint behavior to set the default outbound response format. You can find out more in this question, which also touches on the question conceptual purity: should we be using contract attributes to specify properties that are part of the network protocol? I think Marc Gravell's take on this issue is valid per se, but it is not consistent the original concept of WCF, in which contracts are supposed to be abstracted away from the protocol stack. But endpoint behaviors won't let you specify all REST related attributes, you'll have to use the attributes for URI templates and inbound format.

Could REST have been implemented differently? Although the designers of WCF did an excellent job of designing a generic framework, I don't think they saw REST coming. Some things, like the URI template, really do seem to belong with the contract.

Enough talk! Here's the code. First the web.config file. This is where the magic happens. Note that I'm using WCF 4 configuration based activation in this example, but you could also accomplish the same thing by having 2 svc files to represent the 2 URIs.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <services>
      <service name="StackOverflow.QuoteOfTheDayAsJson">
        <endpoint binding="webHttpBinding" contract="StackOverflow.IQuoteOfTheDay" 
                  behaviorConfiguration="jsonBehavior" />
      </service>
      <service name="StackOverflow.QuoteOfTheDayAsPox">
        <endpoint binding="webHttpBinding" contract="StackOverflow.IQuoteOfTheDay" 
                  behaviorConfiguration="poxBehavior" />
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="jsonBehavior">
          <webHttp defaultOutgoingResponseFormat="Json" />
        </behavior>
        <behavior name="poxBehavior">
          <webHttp defaultOutgoingResponseFormat="Xml"/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="false">
      <serviceActivations>
        <add relativeAddress="QuoteOfTheDayJson.svc" 
             service="StackOverflow.QuoteOfTheDayAsJson"/>
        <add relativeAddress="QuoteOfTheDayPox.svc" 
             service="StackOverflow.QuoteOfTheDayAsPox"/>
      </serviceActivations>
    </serviceHostingEnvironment>
  </system.serviceModel>
</configuration>

And here's the code, including service contract, service implementation, and the type aliases that are necessary to make this work:

namespace StackOverflow
{
    [DataContract]
    public class Quotation
    {
        [DataMember]
        public string Text { get; set; }

        [DataMember]
        public string Author { get; set; }
    }

    [ServiceContract]
    public interface IQuoteOfTheDay
    {
        [OperationContract]
        [WebInvoke(Method="GET", UriTemplate="GetTodaysQuote")]
        Quotation GetTodaysQuote();
    }

    public class QuoteOfTheDayImp : IQuoteOfTheDay
    {
        public Quotation GetTodaysQuote()
        {
            return new Quotation()
            {
                Text = "Sometimes it's better to appologize for not asking permission",
                Author = "Admiral Grace Murray Hopper"
            };
        }
    }

    /// <summary>
    /// A type alias used for json activation
    /// </summary>
    public class QuoteOfTheDayAsJson : QuoteOfTheDayImp 
    {}

    /// <summary>
    /// A type alias used for pox activation
    /// </summary>
    public class QuoteOfTheDayAsPox : QuoteOfTheDayImp
    {}
}

If it weren't for the necessity of the type aliases, I'd say this is a complete solution. It is a complete solution if you don't want to support multiple formats simultaneously. This is superior to the multiple contract solution in the respect that, since there is only one contract, you don't need to keep the 2 contracts in sync.