Введение 3
Постановка задачи 6
Протокол WebSocket и отличия от HTTP 6
Прикладные протоколы, производные от WebSocket 7
Требования к функционалу 8
Структура файла со спецификацией WebSocketAPI веб-сервиса 10
Поле с общей информацией об API 10
Поле с набором определений 11
Поле с набором оконечных точек 11
Тестирование работоспособности отсылки тестовых запросов 12
Данные по умолчанию при подготовке объекта для отсылки тестового запроса 14
Проблема конвертации временных типов из формата веб-сервиса в формат, используемый в проекте 15
Инструменты разработки и технологический стек 16
Технические требования 16
Модули разрабатываемого приложения 17
Технологии, выбранные для реализации системы 17
Язык программирования Java 18
SpringFramework и понятие инверсии контроля 19
ServletAPI и JSP 21
SpringMVC и паттерн MVC 22
SpringWebSocket 24
Система сборки Maven 26
Архитектура проекта 28
Модуль core 28
Классы предметной области 28
FrontEnd-ресурсы 29
Заключение 30
Списокиспользованных источников 31
Приложение 32
Исходный код проекта 32
На сегодняшний день в мире существует и разрабатывается множество веб-сервисов для самых разных целей - интернет-магазины, корпоративные приложения, финансовые системы и т.д.
Каждый веб-сервисимеетАР1 - ApplicationProgrammingInterface - интерфейс работы с приложением, который как правило выглядит как набор оконечных точек, к которым может обратиться другая система или пользователь [1].
Оконечные точки веб-приложения могут быть реализованы различными технологиями и подходами, и в зависимости от технологии определяется то, как обращаться к данным оконечным точкам.
Когда-то основным способом реализации оконечных точек веб-сервисов было использование технологии SOAP, как механизма реализации удаленного вызова процедур (RPC), а в качестве стандарта описания оконечных точек вебсервисов был WSDL, основанный на языке XML [2].
Сегодня, с развитием сети Интернет, все большую популярность набирают другие, более гибкие и легкие с точки зрения разработки и использования стандарты, как RES^ WebSocket. И для эксплуатации API, основанных на этих технологиях, требуются специальные сервисы, позволяющие их описывать. Другими словами, веб-сервис, реализованный к примеру с использованием RESTAPI, может использоваться клиентами, и эти клиенты должны знать, какие оконечные точки есть в этом API, и какой формат обмена данных они имеют [1].
Для описания RESTAPKbLra разработана система инструментов под названием Swagger. Суть ее состоит в том, что разработчики RESTAP^6- сервиса описывают спецификацию интерфейса в файлах со специальной
структурой, которую «умеет» считывать Swagger. Далее, Swaggerиспользует считанное описание АР1 для отображения разработчикам в удобном виде в окне браузера, а также предоставляет разработчикам некоторые дополнительные функции, такие как генерация кода и тестовые вызовы на этот API.
Swaggerявляется достаточно развитым инструментом для описания RESTAPIвеб-сервисов.
Однако, Swaggers подходит для описания API, созданных на основе технологии WebSocket.
Связано это не столько с тем, что Swaggers имеет дополнительного инструмента в своем наборе, предоставляющего такую возможность, а с тем, что работа с протоколом WebSocketфундаментально отличается от работы с RESTAPI [2].
RESTAPI в подавляющем большинстве случаев реализуется поверх
протокола HTTP, либо его защищенного варианта, HTTPS. Взаимодействие с RESTAPIB таком случае состоит в отсылке HTTP-запросов на определенный ЦИи получении ответа от веб-сервиса на данный запрос. Отсюда мы видим синхронную природу HTTP-запросов - клиент ждет, пока сервис вернет какой- то ответ на его запрос.
Взаимодействие с WebSocketAPIпроисходит по другому, асинхронному способу - клиент, посылая сообщение на оконечную точку в WebSocketAPI, не дожидается ответа, поскольку протокол WebSocketa не предполагается посылки ответа на сообщение. Веб-сервис, приняв сообщение от пользователя, может послать ответное сообщение в канал, который «прослушивается» клиентом. Другими словами, протокол WebSocket - это событийноориентированная, асинхронная парадигма передачи сообщений между клиентом и сервером, где как получателем, так и отправителем сообщений может выступать как клиент, так и сервер.
На сегодняшний день не было разработано стабильных, функциональных инструментов, которые предоставляли бы функциональность Swagger, но для протокола WebSocket. В разработке данного инструмента в рамках данной дипломной работы и состояла моя задача.
В ходе выполнения настоящей дипломной работы было разработано клиент-серверное приложение ws-specification-projectдля описания функциональности WebSocketAPIвеб-сервисов.
Основными результатами проведенной работы является реализация серверного АР1приложения, а также реализация клиентского веб-компонента.
Таким образом, приложение на данный момент имеет следующие наработки:
1. Реализована функциональность считывания и парсинга JSON- файлов со спецификацией WebSocketAPI.
2. Реализован графический интерфейс, отображающий считанный API.
3. Реализована возможность выполнять тестовые запросы на веб-сервис.
4. Реализована генерация кода по считанному файлу спецификации API.
Таким образом, все поставленные перед дипломной работой задачи полностью выполнены.
