Методические указания по выполнению лабораторных и практических работ по мдк
 Скачать 3.25 Mb.
|
|
Задание на лабораторную работу Разработать пользовательский интерфейс для веб-клиента, описанного в лабораторной работе № 1. Подготовить макеты для отображения не менее трех страниц для ширины экрана следующего разрешения: - для смартфонов 320 px, 480 px; - планшетов 768 px; - нетбуков и некоторых планшетов 1024 px; - персональных компьютеров 1280 px и более. Вопросы для самопроверки 1. Раскройте понятие «адаптивный веб-дизайн». 2. Зачем нужен адаптивный веб-дизайн? 3. В чем отличие адаптивного сайта от мобильной версии (приложения) сайта? 4. Каковы недостатки адаптивного веб-дизайна? 5. Перечислите основные виды адаптивных макетов. Практическая работа № 1.43. Разработка протокола взаимодействия веб-сервисов Цель работы: изучить принципы проектирования протокола взаимодействия веб- сервисов с использованием протокола SOAP. Теоретический материал Веб-сервисы Веб-служба, веб-сервис (англ. web service) - идентифицируемая уникальным веб-адресом (URL-адресом) программная система со стандартизированными интерфейсами, а также HTML- документ сайта, отображаемый браузером пользователя. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определенных протоколах (SOAP, XML-RPC и т.д.) и соглашениях (REST) . Вебслужба является единицей модульности при использовании сервис- ориентированной архитектуры приложения. На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов: - SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI; - REST (Representational State Transfer); - XML-RPC (XML Remote Procedure Call). На самом деле SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST - это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW. Концепция построения веб-сервисов с использованием SOAP Веб-сервис идентифицируется строкой URI. Веб-сервис имеет программный интерфейс, представленный в машинно-обрабатываемом формате WSDL. Другие системы взаимодействуют с этим веб-сервисом путем обмена сообщениями протокола SOAP. В качестве транспорта для сообщений используется протокол HTTP. Описание веб-сервисов и их API могут быть найдены средствами UDDI. Концептуальная схема технологии приведена на рис. 5.1, где: - SOAP (Simple Object Access Protocol) - протокол обмена сообщениями между потребителем и поставщиком веб-сервиса; - WSDL (Web Services Description Language) - язык описания внешних интерфейсов веб- службы; - UDDI (Universal Discovery, Description and Integration) - универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему. 163 Рис. 5.1. Концепция веб-сервиса Связь между протоколами приведена на рис. 5.2. UDDI Публикация и поиск сервисов WSDL х Описание интерфейсов SOAP Обмен сообщениями HTTP, SMTP, FTP, HOP ... Транспортная инфраструктура Рис. 5.2. Протоколы веб-сервисов Все спецификации, используемые в технологии, основаны на XML и, соответственно, наследуют его преимущества (структурированность, гибкость и т.д.) и недостатки (громоздкость, медлительность). SOAP SOAP - простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP. Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы: - идентификатор сообщения (локальное имя); - опциональный элемент Header (заголовок); - ноль или более ссылок на используемые пространства имен; - ноль или более свойств, доступных в этом пространстве имен; - обязательный элемент Body (тело сообщения); - ноль или более ссылок на используемые пространства имен; - дочерние элементы тела сообщения. Пример SOAP-запроса на сервер интернет-магазина: 12345 Пример ответа: 164 12345 CTaKaH rpaHeHbiA 9.95 840 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. 166 wsoap:mep=" http://www.w3.org/2003/05/soap/mep/soap-response"/ > В данном примере: - веб-сервис 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 . Пример описания сложных структур и списков: 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 - данный код возвращается, если в качестве части запроса был указан неправильный тип содержимого; |