Что такое веб сервисы
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns. Паттерны связывают HTTP методы с тем, что они делают.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
WEB/HTTP сервисы. Базовые отличия и применение на практике
WEB и HTTP сервисы — две технологии, позволяющие получить доступ к 1С из внешней системы. Причем можно получить доступ как за файрволом, так и через прокси. В общем, практически из любой точки земного шара.
С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С и веб-серверы, и клиент, подключающийся к сервису.
Зачем это нужно?
Изначально сервисы разрабатывались для поддержки внешних систем: сайтов, интернет-магазинов, корпоративных порталов. В дальнейшем технология получила широкое распространение и сейчас используется в широком спектре схожих задач:
В качестве примера можно привести сервис обмена данными, который в типовых конфигурациях в части передачи данных реализован также на WEB сервисах. По сравнению с традиционными COM-соединениями он намного более быстр, а информационные базы в этом случае могут базироваться на абсолютно разных платформах: как на версиях, так и на разных операционных системах.
HTTP сервисы, поскольку они достаточно просты, могут выполняться на несложных и недорогих устройствах: таких как микрооборудование, телефония, терминалы сбора данных, электронные весы и так далее. Например, из 1С можно обратиться к IP-телефону, АТС или системе контроля доступа. В нашей практике был кейс, когда с телефонов Yealink вызывался сервис 1С, который записывал входящие звонки. Также это работало и в обратную сторону, и мы могли позвонить непосредственно с карточки клиента одним нажатием кнопки. Реализовывается это легко и быстро.
Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP.
В нашей практике был случай, когда для заказчика нужно было сформировать внешнюю печатную форму на основании обязательной анкеты, которую заполняли клиенты на специальном планшете. Для этого для планшета была сделана веб-страничка. И пока клиенты ждали своей очереди, они заполняли эту страничку, проставляя галки в нужных местах. При нажатии на кнопку «Отправить» данные отправлялись на сервис 1С, где уже всей мощью платформы формировался документ PDF с печатью и подписью, который затем распечатывался и прикреплялся к данным клиента. Все это было сделано за полтора дня, без изменений типовой конфигурации, в расширении.
Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис:
Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:
Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее.
WEB и HTTP сервисы: сходства и различия
WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что:
Теперь расскажем о различиях.
WEB технология — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML.
HTTP сервисы же основаны практически на голом HTTP, и эта технология ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON.
Логично, что WEB-сервисы потенциально сложнее в реализации, потенциально используют больший объем передаваемых данных и дают потенциально большую вычислительную нагрузку.
О форматах данных
Примерно так выглядит XML:
Это, кстати, хороший формат, позволяющий закодировать практически любые данные. А его мощь обеспечивает возможность создания шаблонов XML — XSD-схем, что описывают формат и допустимые типы данных.
Именно поэтому его используют различного рода госорганы.
А так выглядит JSON — формат немного попроще:
Здесь есть основные типы данных: это объекты, формируемые фигурными скобками, массивы, формируемые квадратными скобками, и значение, которое формируется в виде текста.
Данные для HTTP-сервиса передаются в виде запроса HTTP, схематично изображенного ниже:
Он состоит из строки запроса, из заголовка запроса, который представляет собой ключ и значение, также есть пустая строка и тело запроса в виде обычного текста. В теле запроса можно передавать любые данные, в том числе и двоичные, предварительно закодировав их в base64.
Так выглядит строка запроса в HTTP сервисе:
Сервис HTTP ресурсно-ориентирован. Конечные точки, к которым мы можем обращаться, являются ресурсами: они представлены именами существительными. На схеме это элементы строки orders и status, обозначающие соответственно ресурсы «Заказ» и «Статус заказа». Действия над ресурсами выполняются методами HTTP, базовыми из которых являются: get (получить ресурс), post (добавить ресурс), put (обновить ресурс), delete (удалить ресурс). Количество методов HTTP ограничено, действия над ресурсами тоже. Помимо указанных методов есть еще несколько дополнительных, но используются они значительно реже.
Также имеет место понятие коллекции: несколько ресурсов одного типа, из которых можно выбрать один по идентификатору.
Про проектирование
Теперь мы поделимся той болью, которую мы пережили при проектировании API с клиентами и партнерами. И теми шагами, которые необходимо предпринять, чтобы эту боль в будущем чуть-чуть уменьшить.
При создании API предполагается, что пользоваться им будем не только мы, но и партнеры, и пользоваться достаточно долгое время. Здесь не обойтись без тщательного и взвешенного проектирования. Каждый момент должен быть учтен.
Вспоминаем, что HTTP сервис — это у нас, в первую очередь, ресурсы. А ресурсы — это имена существительные: вот таких элементов, как /GetOrders или /orders/add, где в качестве ресурсов явно указываются глаголы действия, быть не должно. В качестве действий у нас должны выступать методы HTTP (get, post, delete).
Правильное проектирование обычно идет по иерархии: коллекция, элемент, ресурс. И вот здесь мы специально отобразили один интересный момент, связанный с особенностями ресурсной иерархии. Например, к заказу у нас прикрепляются накладные. Есть заказ, есть накладные, которые выдаются по этому заказу (одна или несколько). К этим накладным мы можем дать доступ и как к отдельному ресурсу /invoices, и как к ресурсу в составе заказа — когда накладная сделана на основе заказа /orders/
Для проектирования рекомендуется элементы, ресурсы и действия сводить в таблицу, где в строках располагаются ресурсы, а в столбцах — методы HTTP. На пересечениях строк и столбцов — описание, что должно выполняться в данном случае. Пример таблицы:
Благодаря этому мы понимаем, какое действие у нас происходит в случае применения каждого из методов HTTP к соответствующему ресурсу, а также можем легко расширять набор ресурсов и действий над ними.
Про документацию
Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры.
В самом начале мы «забивали» на документацию, а когда партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть.
Документацию мы рекомендуем вести в таком виде:
Вот пример документации. Заголовок, ответ, пример, описание полей данных:
Будь мужиком! Пиши логи!
На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем.
Разделяй код и властвуй над ним
Еще один очень важный момент при проектировании, при разработке таких систем — это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики. Сначала мы делаем обработку самого HTTP запроса, расшифровываем заголовки, тело запроса и результаты передаем в процедуры обработки данных, в другой модуль — модуль бизнес-логики. Для формирование тела запроса и запроса партнеру имеет смысл использовать отдельные общие методы, включающие в себя автоматический вызов функций логирования. И, естественно, мы должны выполнять начальный контроль данных, потому что, в отличие от WEB сервисов, контроль данных у нас не производится.
На примере этого кода продемонстрировано использование указанных выше правил:
В данном случае метод выполняет получение прайса от партнера. При получении производится запись запроса в лог с указанием имени сервиса. Затем выполняется разбор запроса, подготовка данных и формирование ответа на запрос.
Разбор запроса включает в себя чтение и подготовку всех параметров запроса, проверку обязательных параметров и валидацию их корректности.
После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа.
Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром).
Что такое веб-сервис
7 ноября 2017 Опубликовано в разделах: Азбука терминов. 60344
Например, есть авиакомпания. У нее много рейсов, соответственно, много билетов. Информацию через веб-службу она передает сайту-агрегатору тур-путешествий. Пользователь, который заходит на агрегатор, сможет прямо там купить билеты этой авиакомпании.
Другой пример веб-сервисов — это сайт отслеживания погоды, который содержит сведения о метеоусловиях в конкретном городе или по стране в целом. Данная информация также часто используется сторонними приложениями.
Информация в интернете разнородна. Сайты управляются разными системами. используются разные протоколы передачи и шифрования. Веб-сервисы упрощают обмен информацией между разными площадками.
Архитектура и протоколы Web-сервисов
Можно определить 3 инстанции, которые взаимодействуют между собой: каталог, исполнитель и заказчик. После создания сервиса, исполнитель регистрирует его в каталоге, а там сервис находит заказчик.
Механизм обмена данными формируется в описании Web Services Description. Это спецификация, охватывающая форматы пересылки, типы контента, транспортные протоколы, которые применяются в процессе обмена сведениями между заказчиком и транспортировщиком услуг.
Сегодня чаще всего используются несколько технологий для реализации различных веб-сервисов:
Универсальность представленных технологий – основа для понимания веб служб. Они работают на стандартных технологиях, не зависящих от поставщиков приложений и прочих ресурсов сети. Могут использоваться в любых операционных системах, серверах приложений, языков программирования и т.д.
Преимущества
Недостатки
Задачи веб-сервисов
Веб-сервисы могут использоваться во многих сферах.
B2B-транзакции
Интеграция процессов идет сразу, без участия людей. Например, пополнение каталога интернет-магазина новыми товарами. Их привозят на склад, и кладовщик отмечает в базе данных приход. Автоматически информация передается в интернет-магазин. И покупатель вместо пометки “Нет на складе” на карточке товара видит его количество.
Интеграция сервисов предприятий
Если в компании используются корпоративные программы, то веб-сервис поможет настроить их совместную работу.
Создание системы клиент-сервер
Сервисы используются, чтобы настроить работу клиента и сервера. Это дает преимущества:
Веб-сервис — это приложение, которое упрощает техническую настройку взаимодействия ресурсов.
1) Введение в WebService
Что такое веб-сервис?
Веб-сервисы — это механизм или средство связи, посредством которого два приложения / машины будут обмениваться данными независимо от их архитектуры подчеркивания и технологии.
Что такое тестирование веб-службы?
Тестирование веб-сервисов — это тип тестирования программного обеспечения, который проверяет веб-сервисы. Целью тестирования веб-служб является проверка функциональности, надежности, производительности и безопасности API (интерфейса прикладных программ). Тестирование веб-службы в некоторых случаях аналогично тестированию модулей. Вы можете протестировать Web-сервис вручную или создать свой собственный код автоматизации или использовать готовый инструмент автоматизации, такой как Postman.
Зачем нужен веб-сервис?
В общем, программные приложения разрабатываются для использования людьми, когда человек отправляет запрос в службу программного обеспечения, которая, в свою очередь, возвращает ответ в удобочитаемом для человека формате.
В современную технологическую эпоху, если вы хотите создать программное приложение, вам не нужно создавать все с нуля. Существует множество готовых сервисов, которые вы можете подключить к своему приложению, и вы можете начать предоставлять эти сервисы в своем приложении.
Например, вы хотите отображать информацию о прогнозе погоды, которая вам не нужна для сбора, обработки и отображения данных в вашем приложении. Вы можете купить услуги у людей, которые уже хорошо зарекомендовали себя в обработке и публикации такого рода данных.
Веб-сервисы позволяют нам делать такие реализации.
В качестве примера рассмотрим следующий WebService
Это дает стоимость акций для компании.
Давайте найдем цену акции для Google (Символ: GOOG)
XML ответа дает цену акции.
Этот веб-сервис может вызываться программным приложением с использованием протокола SOAP или HTTP.
Протоколы веб-сервисов
Веб-сервисы могут быть реализованы различными способами, но следующие два являются популярными подходами к реализации.
SOAP — это стандартный протокол, определенный стандартом W3C для отправки и получения запросов и ответов веб-служб.
SOAP использует формат XML для отправки и получения запроса и, следовательно, данные являются независимыми от платформы данными. Сообщения SOAP обмениваются между приложениями поставщика и принимающим приложением в конвертах SOAP.
Поскольку SOAP использует простой транспортный протокол http, его сообщения не блокируются брандмауэрами.
ОСТАТОК
REST означает REpresentational State Transfer; это архитектура, которая обычно работает через HTTP. Стиль REST подчеркивает взаимодействия между клиентами и сервисами, которые улучшаются благодаря ограниченному количеству операций. REST является альтернативой SOAP (Simple Object Access Protocol), и вместо использования XML для запроса REST в некоторых случаях использует простой URL. В отличие от SOAP, приложения RESTFUL используют HTTP-заголовки для переноса метаинформации.
Rest API поддерживает формат XML и JSON. Как правило, он предпочтителен для мобильных и веб-приложений, поскольку он делает работу приложений более быстрой и плавной.
WSDL (язык описания веб-сервисов) — это язык на основе XML, который будет использоваться для описания сервисов, предлагаемых веб-сервисом.
WSDL описывает все операции, предлагаемые конкретным веб-сервисом в формате XML. Он также определяет, как могут быть вызваны сервисы, то есть какое входное значение мы должны предоставить и какой будет формат ответа, который он будет генерировать для каждого вида сервиса.
Как проверить веб-сервис?
Для тестирования веб-сервиса вы можете
Тестирование WebService включает в себя следующие шаги:
Предположим, мы хотим протестировать веб-сервис, который предоставляет средство конвертации валют. Это будут текущие курсы обмена между валютами разных стран. Этот сервис мы можем использовать в наших приложениях для преобразования значений из одной валюты в другую валюту.
Теперь давайте посмотрим на шаги выше
Шаг с 1 по 4: Понимание WSDL и определение операций и форматов XML
Файл WSDL Currency Convertor можно увидеть @ ( http://www.webservicex.net/CurrencyConvertor.asmx?wsdl ), который предоставит информацию о методах веб-службы Currency Convertor, которые он будет поддерживать, параметр, который нам нужно передать, и тип параметров… и т. д.
Шаг 5: Использование инструмента или написание кода для отправки запроса и проверки ответа
Для тестирования веб-сервисов доступно множество инструментов. SoapUI — один из популярных инструментов, который поможет нам протестировать веб-сервисы. Фактически вы можете использовать любой язык программирования, который способен отправлять XML-запрос приложению поставщика веб-услуг через http и может анализировать и проверять XML-ответ в соответствии с ожидаемым результатом. В нашем случае мы будем тестировать WebService
ЧАСТЬ 1) Тестирование WebService с использованием Apache Axis2 API (Java).
Обычно веб-служба принимает запрос и отправляет ответ в формате XML.
Axis2 может отправлять сообщения SOAP и получать и обрабатывать сообщения SOAP. Мы можем написать небольшую Java-программу, используя API для создания веб-сервиса. Axis2 сгенерирует WSDL из Java-программы, которая будет использоваться для передачи сервисов, предлагаемых веб-сервисом. Мы можем использовать тот же Axis2 для генерации Java-класса (заглушки) из файла WSDL, который мы можем использовать в качестве клиентской программы для генерации запроса веб-сервиса, отправки запроса конечной точке сервиса и обработки ответа.
Давайте посмотрим на шаги выше в деталях
Шаг а) Загрузите API-интерфейс axis2 @ https://axis.apache.org/axis2/Java/core/download.cgi и установите переменную среды AXIS2_HOME.
Шаг б) Создайте папку для хранения всех сгенерированных артефактов
Пример: C: \ Axis \ Projects \ CurrencyConverter
Шаг c) Откройте командную строку и перейдите к структуре папок, в которой вы хотите создать артефакты, и выполните следующую команду, которая сгенерирует заглушки
Шаг d) После успешного выполнения команды вы увидите папку с необходимыми файлами.
Шаг д) Далее мы должны создать клиентскую программу, с помощью которой мы будем отправлять фактический запрос, используя сгенерированные заглушки. Откройте затмение и создайте новый проект Java и выберите папку, которую мы создали выше.
Шаг f) Добавьте все файлы jar, связанные с axis2, в путь сборки проекта, который будет находиться в папке lib в папке программного обеспечения axis2
(например: C: \ Axis \ axis2-1.6.2 \ lib)
Шаг g) Создайте новый класс Java (например: Client.Java) и создайте экземпляр объекта-заглушки. Используя объект-заглушку, мы можем вызвать все поддерживаемые методы конкретного WebService.
ЧАСТЬ 2) Использование SoapUI для тестирования WebService
Как вы можете заключить, использование таких инструментов, как SoapUI, ускоряет ваши усилия по тестированию WebService. Поэтому SoapUi будет центром нашего обучения в последующих уроках.
Резюме
Часто задаваемые вопросы
В чем разница между WebService и WebAPI?
Веб-сервис
Веб-API
Это руководство стало возможным благодаря участию г-на Нарендера Редди Нукала