Шаблон проектирования для выборочной демонстрации методов через конечные точки SOAP и REST в WCF - PullRequest
Новая
       10

Шаблон проектирования для выборочной демонстрации методов через конечные точки SOAP и REST в WCF

0 голосов
/ 26 июля 2011

У меня есть веб-сервис WCF, который определяет интерфейс IInterface. Этот интерфейс объявляет два метода: Method1 и Method 2. Я хочу предоставить оба этих метода через конечную точку SOAP, но хочу, чтобы только Method2 был доступен через конечную точку REST.

Пример объявления: 

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

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

До сих пор я пытался создать два дополнительных интерфейса: IInterfaceSOAP и IInterfaceREST, оба унаследованных от IInterface. Удалил объявление Method2() из IInterface, добавил его к IInterfaceSOAP и создал два отдельных класса MyServiceSOAP : IInterfaceSOAP и MyServiceREST : IInterfaceREST. Затем определены две отдельные конечные точки для каждого производного класса.

Но когда я тестирую сервис, используя WcfTestClient, мыльный сервис перечисляет только Method1() (тот, который определен в базе IInterface).

Является ли приведенный выше шаблон приемлемым решением для выборочной демонстрации методов через две отдельные конечные точки? Или есть какой-то другой подход, который я пропустил?

Заранее спасибо.

P.S. Обратите внимание, что приведенный выше интерфейс является чрезвычайно упрощенной версией того, что я пытаюсь сделать. В рабочей версии намного больше методов.

Ответы [ 2 ]

0 голосов
/ 26 июля 2011

Неважно ... Из-за огромного количества методов я пропустил Method2.Так как он был определен в производном интерфейсе, все методы базового интерфейса предшествовали этому, и я пропустил его.

0 голосов
/ 26 июля 2011

Этот подход кажется немного вонючим, потому что у вас есть проблемы с развертыванием, вытекающие из ваших сервисных контрактов и реализации.Учитывая, что REST в любом случае не предоставляет метаданных, я не вижу большого преимущества в различных интерфейсах.

Я бы подумал, что поведение или ServiceAuthorizationManager, который проверяет версию сообщения и запрещает доступ для запросов REST, будет более чистым решением.Таким образом, вы могли бы иметь единую реализацию сервиса для одного контракта и отодвинуть проблемы протокола туда, где они находятся: развертывание и настройка.

...