Всё, что нужно знать о REST и SOAP: гайд для тестировщика
Всем привет! Меня зовут Дархан, я QA-инженер компании Creative. Сегодня подробно расскажу об архитектурном стиле REST и формате обмена сообщениями SOAP, в которых нужно шарить любому тестировщику. Статья оформлена в виде простого и понятного гайда – разберём теорию, немного углубимся в детали, а в конце потестим наши запросы на сайте-песочнице. Будет интересно, поэтому давайте начинать. На все вопросы отвечу в конце статьи и, если нужно, разберу ваши кейсы. Погнали!
Базовые понятия о SOAP
SOAP – это протокол обмена сообщениями, который позволяет распределённым элементам приложения обмениваться данными. SOAP может передаваться по множеству стандартных протоколов, он гибкий и независимый. Это позволяет разработчикам писать API на разных языках, а ещё добавлять различные функции и функциональные возможности.
Подход SOAP определяет, как будут обрабатываться сообщения, включенные функции и модули, поддерживаемые протоколы связи.
Информационный набор Extensible Markup Language (XML) используется для SOAP в качестве формата сообщений, а передача и их согласование происходит с помощью протоколов прикладного уровня – таких, как HTTP.
Фишки SOAP
SOAP обладает высокой расширяемостью, но используется только те фрагменты, которые нужны для конкретной задачи.
- Частью волшебства является язык описания веб-служб (WSDL) – ещё один файл, связанный с SOAP. Он показывает, как работает веб-служба, поэтому при создании ссылки на нее среда IDE может полностью автоматизировать процесс.
- SOAP работает с XML, а другим языкам предоставляет ярлыки, которые могут ускорить и облегчить процесс создания запроса и анализа ответа.
- SOAP не терпит ошибок. И это не прикол! В некоторых языках программирования запросы и получение ответов в SOAP нужно будет создавать вручную, поэтому keep calm, please! Сложность зависит от языка программирования.
Знакомимся с REST
RESTful API – это архитектурный стиль интерфейса прикладных программ (API), который использует HTTP-запросы для доступа и использования данных. Их можно использовать для GET, PUT, POST и DELETE, которые относятся к чтению, обновлению, созданию и удалению операций с ресурсами.
Как это работает?
RESTful API разбивает транзакцию на серию небольших модулей. Каждый модуль обращается к базовой части транзакции. Эта модульность предоставляет разработчикам большую гибкость, но вот разработать свой REST API с нуля порой бывает сложно.
Пользоваться можно уже готовыми моделями, самыми популярными сейчас стали Amazon S3, Cloud Data Management Interface (CDMI) и OpenStack Swift.
RESTful API использует команды для получения ресурсов. Состояние ресурса в любой момент времени называется представлением ресурса. RESTful API использует существующие методологии HTTP, определенные протоколом RFC 2616, такие как:
- GET для получения ресурса.
PUT для изменения состояния или обновления ресурса, который может быть объектом, файлом или блоком.
POST для создания этого ресурса.
DELETE, чтобы удалить его.
В REST сетевые компоненты представляют собой ресурс, к которому пользователь запрашивает доступ, подобно чёрному ящику, детали реализации которого неясны. Все вызовы не имеют состояния; служба RESTful ничего не может сохранить между выполнениями.
Какие форматы данных поддерживает REST API:
- приложение/json.
- приложение/xml.
приложение/x-wbe+xml.
- приложение/x-www-форма-urlencoded.
- multipart/form-data.
REST или SOAP
REST и простой протокол доступа к объектам (SOAP) предлагают разные методы вызова веб-службы. И если REST – это, как мы уже разобрали, архитектурный стиль, то SOAP определяет стандартную спецификацию протокола связи для обмена сообщениями на основе XML. Приложения REST могут использовать SOAP.
Веб-службы RESTful не имеют состояния. Реализация на основе REST проста по сравнению с SOAP, но пользователи должны понимать контекст и передаваемое содержимое, поскольку не существует стандартного набора правил для описания интерфейса веб-служб REST.
Службы REST полезны для устройств с ограниченным профилем (таких, как мобильные) и их легко интегрировать с существующими веб-сайтами.
Для SOAP требуется меньше кода (низкоуровневого инфраструктурного кода, который соединяет основные модули кода вместе), чем для проектирования служб REST. Язык описания веб-служб описывает общий набор правил для определения сообщений, привязок, операций и местоположения службы. Веб-службы SOAP полезны для асинхронной обработки и вызова.
А теперь давайте наконец-то потестим наши SOAP и REST запросы.
Тесты методом SOAP
Открываем сайт-песочницу, волшебство будет происходить тут.
Далее нужно зарегистрироваться. Качаем SOAP UI для генерации запросов XML здесь.
Затем создаём SOAP проект (илл.1, 2):
Указываем готовый WSDL , который прописан специально для тестирования SOAP-запросов (илл. 3).
WSDL – это стандартный формат для описания веб-службы.
Сам файл создается на основе XML-тегов (илл. 4):
Дальше SOAP UI генерирует для нас список методов, который был написан в WSDL файле (илл. 5):
Запустим метод doRegister и создадим юзера (илл. 6):
Ниже можно увидеть, что в списке есть юзер с именем Darkhan (илл. 7):
Тесты методом REST
Для этого нам нужно скачать postman, чтобы вызвать запрос.
Дальше берём из документации URL и меняем запрос на POST, чтобы создать юзера (илл. 8):
Когда вы всё написали, можем запускать наш запрос (илл. 9):
И, как показано выше, наш запрос отработал отлично и отдал 200 статус (илл. 10):
На этом мой гайд подходит к концу, надеюсь, я смог объять необъятное и приоткрыть для вас завесу тайны по работе с REST и SOAP запросами. Если у вас есть вопросы или замечания – буду рад продолжить общение в комментариях к статье. Всем лёгких тестов!