Единый сервис WCF REST с несколькими вариантами поведения

#wcf #rest

#wcf #rest

Вопрос:

Возможно ли создать сервис WCF REST 4.0, который имеет две конечные точки с разным поведением? В частности, я ищу одну конечную точку для использования transferMode=Streamed , а другую для использования Buffered .

Я начал использовать приложение WCF REST Service, которое, похоже, представляет собой сочетание технологий маршрутизации WCF и ASP MVC. Я могу установить TransferMode для обеих конечных точек в system.serviceModel/standardEndpoints/webHttpEndpoint/standardEndpoint , но мне не доставляет никакого удовольствия применять дополнительные к моим маршрутам.

Я не совсем понимаю, где существует разделение WCF / MVC, например, считается ли Global.asax одной конечной точкой WCF или маршруты являются отдельными конечными точками, и в результате я не уверен, как продвигаться дальше.

  • Есть ли простое Web.config изменение или атрибут, которые я могу применить к сервису, чтобы указать другое поведение?
  • Если нет, могу ли я создать отдельные файлы asax, используя разные варианты поведения вместо одного Global.asax файла?
  • Если нет, должен ли я создать файлы .svc для сопоставления с моими классами, как в обычном приложении WCF?
  • Если нет, придется ли мне создавать второй проект для определения другого поведения?

Ответ №1:

Каждый маршрут обслуживания создает новый ServiceHost. Кроме того, REST Starter Kit теперь устарел, либо вам следует использовать обычный WCF REST 4.0, либо вам следует ознакомиться с новым материалом WCF Web API наhttp://wcf.codeplex.com

Комментарии:

1. Извините за упоминание starter kit, на самом деле это приложение-служба WCF Rest.

2. Приветствия. Знаете ли вы какой-либо способ, которым узлы службы могут быть настроены отдельно? Предпочтительно более легкий способ, чем определение узла пользовательской службы.

Ответ №2:

Как насчет того, чтобы сделать это таким образом:

 <services>
  <service name="YourNamespace.YourServiceClass">
    <endpoint address="stream" kind="webHttpEndpoint" endpointConfiguration="webHttpStreamed" contract="YouServiceContract" />
    <endpoint address="buff" kind="webHttpEndpoint" endpointConfiguration="webHttpBuffered" contract="YouServiceContract" />
  </service>
</services>

<standardEndpoints>
  <webHttpEndpoint>
    <standardEndpoint name="webHttpStreamed" transferMode="Streamed" />
    <standardEndpoint name="webHttpBuffered" transferMode="Buffered" />
  </webHttpEndpoint>
</standardEndpoints>
  

Конечно, адреса двух конечных точек не должны перекрываться.

Комментарии:

1. Отлично, это именно тот подход, на который я надеялся, будет возможен 🙂 Я добавил раздел service и вторую стандартную конечную точку; все запросы, которые соответствуют адресу конечной точки, используют эту конфигурацию, а все остальные запросы проходят через стандартную конечную точку по умолчанию без имени. (Единственная ложка дегтя в бочке меда заключается в том, что я должен указать абсолютный адрес, чтобы поставить https впереди, иначе он не сможет определить, что у меня есть безопасность транспорта).