WCF сервис. Создание сервиса, использующего методы Post и Get

Запись от Lenoshka размещена 04.06.2014 в 13:17

Показов 12706 Комментарии 0

Итак, постараюсь рассказать, как создать простенький сервис с тремя методами для различных потребностей.
Информации на просторах Интернета много, но есть нюансы, с которыми пришлось повозиться. Именно на них я и сделаю акцент в статье.
Создание сервиса.
Запускаем студию и создаем новый проект WCF Service Applikation с красивым и понятным названием.
После нажатия кнопки ОК откроется сам проект уже с шаблоном. Можно его удалить, т.к. я все буду делать по-другому.
Методы сервиса описываются в интерфейсе, а уже их реализация описывается в программе.
Чтобы описать наши методы (их будет 3), нужно открыть файл IService1.cs.
Файлы, конечно же, лучше переименовать с учетом целей вашего проекта.
Создавать будем 3 метода
EchoGet — принимает данные методом get (т.е. данные для вносятся в строку uri)
EchoPost — принимает данные методом post (тоже через строку uri)
EchoPostStream — принимает данные методом post, но уже затолканные через входящий поток.
Код объявления методов выглядит следующим образом:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[ServiceContract]
    public interface IService1
    {
 
        [OperationContract]
        string EchoGet(string value);
 
        [OperationContract]
        string EchoPost(string value);
 
        [OperationContract]
        string EchoPostStream(Stream value);
 
      }

Теперь каждому методу нужно рассказать, каким же образом он будет получать сообщения. Для этого служат атрибуты WebGet (для приема сообщения мотодом get) и WebInvoke (для приема сообщения методом post):

C#
1
2
3
4
5
6
7
8
9
10
11
  [OperationContract]
        [WebGet]
        string EchoGet(string value);
 
        [OperationContract]
        [WebInvoke]
        string EchoPost(string value);
 
        [OperationContract]
        [WebInvoke]
        string EchoPostStream(Stream value);

Следующим шагом будет описание в методе, где именно в uri будет передаваемая информация. Для этого нужно описать шаблон при помощи указания UriTemplate.

C#
1
2
3
 [OperationContract]
        [WebInvoke(UriTemplate="/{value}")]
        string EchoPost(string value);

По-умолчанию считается, что в методах WebInvoke данные передаются методом POST, но лучше это прописать явно:
[OperationContract]
[WebInvoke(Method="POST", UriTemplate="/{value}")]
string EchoPost(string value);

C#
1
2
3
 [OperationContract]
        [WebInvoke(Method="POST")]
        string EchoPostStream(Stream value);

Метод передается как строка!
Собственно, пока все. Можно начинать описывать реализацию.
В описании ничего замысловатого нет: приняли строку/поток и вернули строку.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 public string EchoGet(string value)
        {
            return value;
        }
 
        public string EchoPost(string value)
        {
            return value;
        }
 
        public string EchoPostStream(Stream value)
        {
            StreamReader reader = null;
            reader = new StreamReader(value);
            string str = reader.ReadToEnd();
            return str;
        }

Как бы все. Можно начинать тестировать. Это действо лучше проводить с помощью Fiddlera. По крайней мере можно будет задать тип контента, что очень важно в некоторых случая, и посмотреть, что вообще происходит.
Итак, запускаем наш сервис. Первые два метода можно протестировать прямо в студии. Для этого имеется специальный WCF Test Client. Выбираете метод в левой части экрана, пишите входящее значение в столбце Value, нажимаете кнопку Invoke и получаете результат деятельности сервиса в нижней части окна (pic1).
Есть один нюанс: он откроется только если нажать кнопку Run при активной вкладке с реализацией методов — Service1.svc.cs. В противном случае откроется браузер с информацией о сервисе. (pic2)
Но методы работать в сети не будут. Все дело в том, что нужно описать конечную точку, т.е. куда методы будут отправлять результат своей работы.
Наш конфиг выглядит так:

XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0"?>
 
<configuration>
  <system.serviceModel>
    <services>
      <service name="WCF_test.Service1">
        <endpoint address="" behaviorConfiguration="WebBehavior" binding="webHttpBinding" contract="WCF_test.IService1"/>
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="WebBehavior">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
  <system.web>
    <compilation debug="true"/>
  </system.web>
</configuration>

В двух словах ключевые моменты:

XML
1
<service name="WCF_test.Service1">

— name состоит из имени namespace и имени класса-наследника интерфейса с описанием методов.

XML
1
<endpoint address="" behaviorConfiguration="WebBehavior" binding="webHttpBinding" contract="WCF_test.IService1"/>

— это конечная точка, binding — это привязка конечной точки, которая описывает «как» мы передаем данные. В нашем случае мы будем передавать данные через сеть, поэтому значение webHttpBinding.
Если мы укажем другие значения привязки, мы не сможем работать с фиддлером и браузером, но указав эту привязку, мы не сможем тестировать сервис через тест-клиент студии.

Итак, сервис запущен. Нужно узнать, через какой порт он получает информацию. Для этого обратимся к окну браузера, которое открывается при запуске: в адресной строке пишется адрес с номером порта.
http://localhost:22493/Service1.svc
Теперь можно проверить жизнеспособность методов.
Метод, передающий запрос с помощью метода get можно протестировать в браузере, введя в адресную строку следующее:
http://localhost:22493/Service... alue=Hello!

Первое, что идет за именем сервиса (Service1.svc) — косая черта, за ней — имя вызываемого метода (EchoGet). Знак вопроса после него говорит, что дальше будут идти переменные: value — имя переменной, Hello — ее значение.
Вот какой результат получился (pic3)
В фиддлере это выглядит т.о.(pic4)
В правой части: в адресной строке запрос к нашему методу с указанием переменной и ее значения.
В левой части: результат работы. Значение результата 200 говорит о том, что все прошло хорошо и наш сервис нам что-то вернул. Двойной щелчок по строке с результатом откроет нам следующее окно: (pic5)
Результат в нижней части.

Следующие методы в браузере уже не протестируем, поэтому обращаемся к Фиддлеру.
Метод EchoPost получает данные также через адресную строку. Мы даже объявили шаблон для того, чтобы метод знал, где эти данные искать:

C#
1
UriTemplate="/{value}"

В фигурных скобках указано имя переменной, именно на этом и будет ее искать метод. Значит запрос к методу будет выглядеть следующим образом: хост, порт, имя сервиса и… нет, не имя метода, а значение переменной.
Да, в этом подвох: имя метода в этом случае не указывается.(pic6)
Результат можно увидеть опять же, с помощью двойного щелчка по строке с результатом в правой части: (pic7)
Остался третий и самый подлый метод. Почему подлый? Да отнял у меня не один день жизни, пока я поняла, что он от меня хочет.

Вызвать его можно указав в адресной строке после имени сервиса имя метода, а в нижней части текст сообщения, которое пойдет в поток (pic8)
Результат (pic9)
С какими трудностями столкнулась я: иногда нужно указать тип входящего контента.
Это делается так: в окне request Header пишется следующая строка:
Content-Type: application/xml
По крайней мере так советуют многое специалисты в своих блогах. НО! Именно в моем случае тип был application/octet-stream
Если тип указан не верно, то будет ошибка 400.
Теперь о том, как узнать тип. Придумала не сама, а наткнулась в сети вот здесь:
https://vivekcek.wordpress.com... /#comments

Если кто-нибудь увидит в статье недочеты — пишите. Я же только учусь

Размещено в Без категории

« Отчет ReportViewer. История создания Главная страница

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.

Всего комментариев 0

Комментарии

Новые блоги и статьи Все статьи Все блоги /
Жара жесть. kumehtar 18.08.2026 Пролетают летом дни Тридцать пять жары в тени. Каждый август год от года Дарит жаркую погоду.	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .
Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .

Сообщение форума

Отменить изменения