[SOLVED] Is there any value in separating wcf service contracts from your interface definition?

Is there any value in separating wcf service contracts from your interface definition?

I have an interface ICustomerService:

public interface ICustomerService
{

  CustomerList FindAll();
}

and a concrete class implementing that interface. Now I need to expose the method over the web using wcf/rest and I've had to change the interface definition to this:

[ServiceContract]
public interface ICustomerService
{
  [OperationContract]
  [WebInvoke(
   Method = "GET",
   UriTemplate = "Customers")]
  CustomerList FindAll();
}

My question is if there is any downside to having these attributes attached to your interface if there are clients that want to use the implementation using dll reference instead of using the rest api? I am aware of the shortcomings in using REST like having to have your parameters as type string if its in the uri.

Solution

There should be no downsides of the attributes except maybe in code readability (if your clients have to look at your interface source).

The attributes can be read by anyone interested (like the WCF framework) or will be ignored. Actually they won't be visible from any implementing class (see this question).

At the architecture level however, consider using 2 interfaces, one for the dll-referencing clients and one for the REST clients. They might be similar the begin with, they might even share the same base interface and implementation, but you have the ability to make them divert from each other if the business case requires it.
Also, this gives you the possibility to keep the WCF attribute filled interfaces in the WCF web application project, and the clean interfaces and implementations in a core class library project.