Вы можете выставить сервис в двух разных конечных точках. в SOAP можно использовать привязку, поддерживающую SOAP, например basicHttpBinding, в RESTful можно использовать webHttpBinding. Я предполагаю, что ваша служба REST будет в JSON, в этом случае вам нужно настроить две конечные точки со следующей конфигурацией поведения
Еще один способ сделать это - выставить два разных сервисных контракта и каждый с определенной конфигурацией. Это может создать некоторые дубликаты на уровне кода, однако в конце дня вы хотите, чтобы он работал.
Как это выглядит, когда я размещаю .svc в IIS в каком-то виртуальном каталоге, например someserver / myvirtualdir / service.svc ? Как мне получить к нему доступ?
Это говорит о том, что мой контракт IEvents недействителен, когда я пытаюсь сослаться на мой интерфейс службы: <имя службы = "События"> <адрес конечной точки = "json" binding = "webHttpBinding" поведениеConfiguration = "jsonBehavior" contract = "IEvents" />. Мой IEvents имеет атрибут [ServiceContract] на интерфейсе, поэтому не уверен, почему. </ service>
PositiveGuy
Я могу получить localhost: 44652 / MyResource / json для работы, но я не могу получить идентификатор для работы localhost: 44652 / MyResource / 98 / json . Я пытался добавить UriTemplate с "/ {id}", также пробовал "events / {id}, но он не находит его, когда я пытаюсь попасть в сервис. Работает только первый, не уверен, как получить последний на работу.
PositiveGuy
2
Как это может работать без физического файла там? Я просто, кажется, получаю 404 ошибки, должно быть чего-то не хватает
RoboJ1M
39
На этот пост уже получен очень хороший ответ от "Сообщества вики", и я также рекомендую взглянуть на веб-блог Рика Страла, там много хороших постов о WCF Rest, как это .
Я использовал оба, чтобы получить этот вид MyService-сервиса ... Тогда я могу использовать REST-интерфейс из jQuery или SOAP из Java.
На самом деле я использую только Json или Xml, но они оба здесь для демонстрационных целей. Это GET-запросы для получения данных. Для вставки данных я бы использовал метод с атрибутами:
Это для целей тестирования. Просто чтобы посмотреть, работают ли ваши конечные точки. Вы смотрели на SoapUI? soapui.org
Даррел Миллер
@TuomasHietanen - я не получаю ответ типа JSON, используя поведение webHttp, но используя enableWebScript, я получаю ответ типа JSON. Я поместил ResponseFormat как WebMessageFormat.Json. С другой стороны, я не могу использовать URItemplate, если я использую поведение enableWebScript. Любые идеи?
smile.al.d.way
1
@CoffeeAddict - Почему вы должны использовать интерфейс? Просто иметь интерфейс? Вы не будете использовать этот интерфейс никогда. Это проще
Туомас Хиетанен
25
Если вы хотите разработать только один веб-сервис и разместить его на разных конечных точках (например, SOAP + REST с выходами XML, JSON, CSV, HTML). Вы также должны рассмотреть возможность использования ServiceStack который я построил именно для этой цели, когда каждый разрабатываемый вами сервис автоматически доступен на конечных точках SOAP и REST "из коробки" без какой-либо настройки.
В Hello World пример показывает , как создать простой с сервисом с только (не требуется конфигурации):
Он также поставляется с дружественным HTML-выводом (при вызове с HTTP-клиентом, который имеет Accept: text / html, например, браузер), чтобы вы могли лучше визуализировать выходные данные своих служб.
Обработка различных глаголов REST также тривиальна, вот полное CRUD-приложение REST-service на 1 странице C # (меньше, чем требуется для настройки WCF;):
По умолчанию Windows Communication Foundation (WCF) делает конечные точки доступными только для клиентов SOAP. В разделе Практическое руководство. Создание базовой веб-службы WCF HTTP конечная точка становится доступной для клиентов, не являющихся SOAP. Могут возникнуть ситуации, когда вы захотите сделать один и тот же контракт доступным в обоих случаях, в качестве конечной точки Web и конечной точки SOAP. В этой теме показан пример того, как это сделать.
Это то, что я сделал, чтобы это сработало. Убедитесь, что вы поместили webHttp automaticFormatSelectionEnabled = "true" в поведение конечной точки.
[ServiceContract]publicinterfaceITestService{[WebGet(BodyStyle=WebMessageBodyStyle.Bare,UriTemplate="/product",ResponseFormat=WebMessageFormat.Json)]stringGetData();}publicclassTestService:ITestService{publicstringGetJsonData(){return"I am good...";}}
<endpointBehaviors><behaviorname="jsonBehavior"><webHttpautomaticFormatSelectionEnabled="true"/><!-- use JSON serialization --></behavior></endpointBehaviors>
Ответы:
Вы можете выставить сервис в двух разных конечных точках. в SOAP можно использовать привязку, поддерживающую SOAP, например basicHttpBinding, в RESTful можно использовать webHttpBinding. Я предполагаю, что ваша служба REST будет в JSON, в этом случае вам нужно настроить две конечные точки со следующей конфигурацией поведения
Примером конфигурации конечной точки в вашем сценарии является
Итак, сервис будет доступен на
Примените [WebGet] к операционному контракту, чтобы сделать его RESTful. например
Обратите внимание: если служба REST отсутствует в JSON, параметры операций не могут содержать сложный тип.
Ответ на сообщение для SOAP и RESTful POX (XML)
Для простого старого XML в качестве возвращаемого формата это пример, который будет работать как для SOAP, так и для XML.
Поведение POX для REST Plain Old XML
Endpoints
Сервис будет доступен на
Запрос REST попробуйте в браузере,
Конфигурация конечной точки клиента SOAP-запроса для службы SOAP после добавления ссылки на службу,
в C #
Еще один способ сделать это - выставить два разных сервисных контракта и каждый с определенной конфигурацией. Это может создать некоторые дубликаты на уровне кода, однако в конце дня вы хотите, чтобы он работал.
источник
На этот пост уже получен очень хороший ответ от "Сообщества вики", и я также рекомендую взглянуть на веб-блог Рика Страла, там много хороших постов о WCF Rest, как это .
Я использовал оба, чтобы получить этот вид MyService-сервиса ... Тогда я могу использовать REST-интерфейс из jQuery или SOAP из Java.
Это из моего Web.Config:
И это мой класс обслуживания (.svc-codebehind, интерфейсы не требуются):
На самом деле я использую только Json или Xml, но они оба здесь для демонстрационных целей. Это GET-запросы для получения данных. Для вставки данных я бы использовал метод с атрибутами:
источник
Если вы хотите разработать только один веб-сервис и разместить его на разных конечных точках (например, SOAP + REST с выходами XML, JSON, CSV, HTML). Вы также должны рассмотреть возможность использования ServiceStack который я построил именно для этой цели, когда каждый разрабатываемый вами сервис автоматически доступен на конечных точках SOAP и REST "из коробки" без какой-либо настройки.
В Hello World пример показывает , как создать простой с сервисом с только (не требуется конфигурации):
Никаких других настроек не требуется, и эта служба сразу же доступна с REST в:
Он также поставляется с дружественным HTML-выводом (при вызове с HTTP-клиентом, который имеет Accept: text / html, например, браузер), чтобы вы могли лучше визуализировать выходные данные своих служб.
Обработка различных глаголов REST также тривиальна, вот полное CRUD-приложение REST-service на 1 странице C # (меньше, чем требуется для настройки WCF;):
источник
У MSDN сейчас есть статья для этого:
https://msdn.microsoft.com/en-us/library/bb412196(v=vs.110).aspx
Вступление:
источник
Мы должны определить конфигурацию поведения для конечной точки REST
а также к услуге
После поведения следующий шаг - привязки. Например, basicHttpBinding для конечной точки SOAP и webHttpBinding для REST .
Наконец, мы должны определить конечную точку 2 в определении сервиса. Внимание для адреса = "" конечной точки, где службе REST ничего не нужно.
В интерфейсе сервиса мы определяем работу с ее атрибутами.
Присоединяясь ко всем сторонам, это будет наше определение system.serviceModel WCF.
Чтобы протестировать обе конечные точки, мы можем использовать WCFClient для SOAP и PostMan для REST .
источник
Это то, что я сделал, чтобы это сработало. Убедитесь, что вы поместили
webHttp automaticFormatSelectionEnabled = "true" в поведение конечной точки.
Внутренняя сервисная модель
Поведение конечной точки
источник