164 12345 CTaKaH rpaHeHbiA CTaKaH граненый. 250 M.n. 9.95 840 USD $ US dollar 2
true
WSDL Язык описания веб-сервисов (Web services Description Language, WSDL) предназначен для унифицированного представления внешних интерфейсов веб-службы. Текущая версия протокола (на момент написания этой лекции) WSDL 2.0 и она имеет некоторые отличия от предыдущих версий приведенные в табл. 5.1 и на рис. 5.3. Таблица 5.1 Основные элементы протокола WSDL Элемент WSDL 1.1 Элемент WSDL 2.0 Краткое описание PortType Interface Представляет описание интерфейса веб-сервиса (список операций и их параметров) Service Service Список системных функций Binding Binding Специфицирует интерфейсы и задает параметры связывания с протоколом SOAP: стиль связывания (RPC/Document) и транспорт (SOAP). Эта секция доступна и для каждой из операций Operation Operation Определяет операцию, представляемую веб-сервером. WSDL- операция — это аналог традиционным функциям и процедурам Message — Сообщение, связанное с определенной операцией. Содержит информацию, необходимую для выполнения данной операции. Каждое сообщение может состоять из нескольких логических частей, описывающих типы данных и имена атрибутов. В версии 2.0 было исключено, так как была внедрена поддержка XML Schema для всех элементов Types Types Описание данных в соответствии с XML Schema
165 Рис. 5.3. Структура протокола WSDL В спецификации WSDL 1.1 было определено четыре шаблона обмена сообщениями (типы операций): - однонаправленные операции (One-way): операция может принимать сообщение, но не будет возвращать ответ; - запрос-ответ (Request-response): операция может принять запрос и должна вернуть ответ; - вопрос-ответ (Solicit-response): операция может послать запрос и будет ждать ответ на него; - извещение (Notification): операция может послать сообщение, но не будет ожидать ответ. В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1. Пример описания веб-сервиса на языке WSDL (версия 2.0):
Hello_WSDL_20_SOAP.wsdl Copyright (c) 2009 HerongYang.com, All Rights Reserved.
В данном примере: - веб-сервис helloService определен с эндпойнтом helloEndpoint, доступным по адресу http://www.herongyang.com/Service/Hello_ SOAP_12.php; - эндпойнт helloEndpoint ссылается на связывание helloBinding; - связывание helloBinding определено с использованием протокола SOAP 1.2 поверх HTTP; - связывание helloBinding ссылается на интерфейс hellointerface; - интерфейс helloInterface определеляет операцию Hello, которая требует элементы входящего и исходящего сообщений; - каждый элемент Hello/HelloResponse определяет в XML-схеме секции types . Пример описания сложных структур и списков: FormDefault="qualified" targetNamespace=" http://localhost/ "> /> /> />
В данном примере представлено: - описание структуры Message, состоящей из полей phone, text, date, type; - описание списка сообщений MessageList, состоящего из неограниченного количества элементов типа Message;
167 - описание запроса Request со списком сообщений; - описание ответа Response с булевской переменной, содержащей статус выполнения запроса. UDDI Universal Description, Discovery and Integration (UDDI - универсальный интерфейс распознавания, описания и интеграции) - открытый стандарт, утвержденный OASIS, определяющий методы публикации и обнаружения сетевых программных компонентов сервис- ориентированной архитектуры (SOA) . В практической реализации UDDI представляет собой сетевой реестр (службу каталогов) , представляющий данные и метаданные о веб-сервисах и доступный по адресу: URL: http:// uddi.xml.org/services. Задание на лабораторную работу Разработать протокол взаимодействия сервера и клиентов, описанных в лабораторной работе № 1: 1. Подготовить WSDL-описание команд сервера. 2. Подготовить примеры SOAP запросов и ответов в соответствии с WSDL-описанием. Вопросы для самопроверки 1. Что такое веб-сервис? 2. Что такое сервис-ориентированная архитектура?
Нефтеюганск 2021 3. Какие протоколы реализации веб-сервисов получили наибольшее распространение? 4. Опишите структуру SOAP сообщения. 5. В чем отличие спецификаций WSDL 1.1 от WSDL 2.0? Практическая работа № 1.44. Разработка REST API. Практическая работа № 1.45. Разработка REST API Цель работы: изучить принципы проектирования протокола взаимодействия веб- сервисов согласно архитектурному стилю взаимодействия компонентов распределенного приложения в сети REST. Теоретический материал REST REST (Representational state transfer) - это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения вебслужб. Термин REST был введен в 2000 г. Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами. В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат. Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные, т.е. данные не заворачиваются в XML, как это делает SOAP и XML- RPC. Каждая единица информации однозначно определяется URL - это значит, что URL, по сути, является первичным ключом для единицы данных, т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35-я страница в этой книге - /book/3/page/35. Отсюда и полу- чается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 - это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word. Наиболее широко распространенные инструменты для описания RESTful API: - www.mashape.com - www.swagger.io - www.apiary.io HTTP-методы Как происходит управление информацией сервиса - это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол - HTTP. Для HTTP действие над данными задается с помощью методов. Проектирование операций на HTTP-методы становится легче, когда вы знаете характеристики всех методов HTTP. Ниже представлены две характеристики, которые должны быть определены перед использованием HTTP-метода: - безопасность: HTTP-метод считается безопасным, когда вызов этого метода не изменяет состояние данных. Например, когда вы извлекаете данные с помощью метода GET - это безопасно, потому что этот метод не обновляет данные на стороне сервера; - идемпотентность: когда вы получаете один и тот же ответ, сколько раз вы вызываете один и тот же ресурс, он известен как идемпотентный. Например, когда вы пытаетесь обновить одни и те же данные на сервере, ответ будет таким же для каждого запроса, сделанного с одинаковыми данными. Не все методы являются безопасными и идемпотентными. В табл. 6.1 представлен список методов, которые используются в REST-приложениях и показаны их свойства.
2 Таблица 6.1. REST-методы HTTP-метод Безопасный Идемпотентный GET Да Да POST Нет Нет PUT Нет Да DELETE Нет Да OPTIONS Да Да HEAD Да Да Ниже приведен краткий обзор каждого метода и рекомендации по их использованию: - GET: метод является безопасным и идемпотентным. Обычно используется для извлечения информации и не имеет побочных эффектов; - POST: метод не является ни безопасным, ни идемпотентным. Этот метод наиболее широко используется для создания ресурсов; - PUT: метод является идемпотентным. Вот почему лучше использовать этот метод вместо POST для обновления ресурсов. Избегайте использования POST для обновления ресурсов; - DELETE: как следует из названия, метод используется для удаления ресурсов. Но этот метод не является идемпотентным для всех запросов; - OPTIONS: метод не используется для каких-либо манипуляций с ресурсами. Но он полезен, когда клиент не знает других методов, поддерживаемых для ресурса, и используя этот метод, клиент может получить различное представление ресурса; - HEAD: этот метод используется для запроса ресурса c сервера. Он очень похож на метод GET, но HEAD должен отправлять запрос и получать ответ только в заголовке. Согласно спецификации HTTP, этот метод не должен использовать тело для запроса и ответа; - HTTP: определяет различные коды ответов для указания клиенту различной информации об операциях. Далее представлен список кодов ответов HTTP: - 200 OK - это ответ на успешные GET, PUT, PATCH или DELETE. Данный код также используется для POST, который не приводит к созданию; - 201 Created - данный код состояния является ответом на POST, который приводит к созданию; - 204 Нет содержимого - это ответ на успешный запрос, который не будет возвращать тело (например, запрос DELETE); - 304 Not Modified - используйте этот код состояния, когда заголовки HTTP-кеширования находятся в работе; - 400 Bad Request - данный код состояния указывает, что запрос искажен, например, если тело не может быть проанализировано; - 401 Unauthorized - данный код возвращается, если не указаны или недействительны данные аутентификации. Также полезно активировать всплывающее окно auth, если приложение используется из браузера; - 403 Forbidden - данный код возвращается, когда аутентификация прошла успешно, но аутентифицированный пользователь не имеет доступа к ресурсу; - 404 Not found - данный код возвращается, если запрашивается несуществующий ресурс; - 405 Method Not Allowed - данный код возвращается, когда запрашивается HTTP-метод, который не разрешен для аутентифицированного пользователя; - 410 Gone - данный код состояния указывает, что ресурс в этой конечной точке больше не доступен. Полезно в качестве защитного ответа для старых версий API; - 415 Unsupported Media Type - данный код возвращается, если в качестве части запроса был указан неправильный тип содержимого;
3 - 429 Too Many Requests - данный код возвращается, когда запрос отклоняется из-за ограничения скорости; - 500 - внутренняя ошибка сервера.