Wcf – Handling versioning for clients when using WCF

You can expose the service in two different endpoints. the SOAP one can use the binding that support SOAP e.g. basicHttpBinding, the RESTful one can use the webHttpBinding. I assume your REST service will be in JSON, in that case, you need to configure the two endpoints with the following behaviour configuration

<endpointBehaviors>
  <behavior name="jsonBehavior">
    <enableWebScript/>
  </behavior>
</endpointBehaviors>

An example of endpoint configuration in your scenario is

<services>
  <service name="TestService">
    <endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
    <endpoint address="json" binding="webHttpBinding"  behaviorConfiguration="jsonBehavior" contract="ITestService"/>
  </service>
</services>

so, the service will be available at

• http://www.example.com/soap
• http://www.example.com/json

Apply [WebGet] to the operation contract to make it RESTful. e.g.

public interface ITestService
{
   [OperationContract]
   [WebGet]
   string HelloWorld(string text)
}

Note, if the REST service is not in JSON, parameters of the operations can not contain complex type.

Reply to the post for SOAP and RESTful POX(XML)

For plain old XML as return format, this is an example that would work both for SOAP and XML.

[ServiceContract(Namespace = "http://test")]
public interface ITestService
{
    [OperationContract]
    [WebGet(UriTemplate = "accounts/{id}")]
    Account[] GetAccount(string id);
}

POX behavior for REST Plain Old XML

<behavior name="poxBehavior">
  <webHttp/>
</behavior>

Endpoints

<services>
  <service name="TestService">
    <endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
    <endpoint address="xml" binding="webHttpBinding"  behaviorConfiguration="poxBehavior" contract="ITestService"/>
  </service>
</services>

Service will be available at

• http://www.example.com/soap
• http://www.example.com/xml

REST request try it in browser,

http://www.example.com/xml/accounts/A123

SOAP request client endpoint configuration for SOAP service after adding the service reference,

  <client>
    <endpoint address="http://www.example.com/soap" binding="basicHttpBinding"
      contract="ITestService" name="BasicHttpBinding_ITestService" />
  </client>

in C#

TestServiceClient client = new TestServiceClient();
client.GetAccount("A123");

Another way of doing it is to expose two different service contract and each one with specific configuration. This may generate some duplicates at code level, however at the end of the day, you want to make it working.

Below are my observations from experiences:

SignalR pros:

• Easy to startup, lower learning curve. You can easily run an example found from web
• Exception handling (e.g. connection drops, timeouts) is embedded inside the API

SignalR cons:

• Only supporting HTTP protocol

Duplex pros:

• Supports TCP in addition to HTTP. This may be a serious performance gain if you know your client types and your system is working in a closed network. Also, working over TCP adds more connection stability than HTTP

Duplex cons:

• Higher learning curve - harder to startup and have a stable solution. Want to verify it? Download a duplex and a SignalR sample from the web and see how much time you will spend to successfully run each other.
• You need to handle all the exceptional cases (connection drops, timeouts, etc.)
• I know I am not the only one who faced serious timeout problems when you want to use the duplex service for a long time. We need to make service calls periodically to keep client connections alive.

By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.