Design Pattern for selectively exposing methods through SOAP and REST endpoints in WCF

Question

I have a WCF web service that defines IInterface interface. This interface declares two methods: Method1 and Method 2. I want to expose both of these methods through a SOAP endpoint, but want only Method2 exposed through REST endpoint.

Example declarations:

[ServiceContract]
public Interface IInterface
{
    [OperationContract]
    void Method1();
    [OperationContract]
    void Method2();
}

public class MyService : IInterface
{
    public void Method1(){...}
    public void Method2(){...}
}

So far I have tried creating two additional interfaces: IInterfaceSOAP and IInterfaceREST , both inherited from IInterface . Removed Method2() declaration from IInterface and added it to IInterfaceSOAP and created two separate classes MyServiceSOAP : IInterfaceSOAP and MyServiceREST : IInterfaceREST . Then defined two separate endpoints for each derived class.

But when i test the service using WcfTestClient , the soap service only lists Method1() (the one that's defined in the base IInterface ).

Is the above pattern an accepted solution for selectively exposing methods through two separate endpoints? Or is there some other approach that I have missed?

Thanks in advance.

PS Please note the above interface is extremely simplified version of what i'm trying to do. There are a lot more methods in the production version.

Answer 1

This approach seems a little smelly in that you have deployment concerns leaking into your service contracts and implementation. Given that REST does not expose metadata anyway I don't see a lot of benefit in the different interfaces.

I would have thought a behavior or ServiceAuthorizationManager, which examined the message version and disallowed access for REST requests would be a cleaner solution. That way you could have a single service implementation for a single contract and push protocol issues back to where they belong: deployment and configuration.

Answer 2

Nevermind... Due to huge number of methods i missed Method2. Since it was defined in a derived Interface, all methods in the base Interface came before this one and i missed it.