Вариант 8408
Разработать спецификацию в формате OpenAPI для набора веб-сервисов, реализующего следующую функциональность:
Первый веб-сервис должен осуществлять управление коллекцией объектов. В коллекции необходимо хранить объекты класса City
Веб-сервис должен удовлетворять следующим требованиям:
- API, реализуемый сервисом, должен соответствовать рекомендациям подхода RESTful.
- Необходимо реализовать следующий базовый набор операций с объектами коллекции: добавление нового элемента, получение элемента по ИД, обновление элемента, удаление элемента, получение массива элементов.
- Операция, выполняемая над объектом коллекции, должна определяться методом HTTP-запроса.
- Операция получения массива элементов должна поддерживать возможность сортировки и фильтрации по любой комбинации полей класса, а также возможность постраничного вывода результатов выборки с указанием размера и порядкового номера выводимой страницы.
- Все параметры, необходимые для выполнения операции, должны передаваться в URL запроса.
- Информация об объектах коллекции должна передаваться в формате xml.
- В случае передачи сервису данных, нарушающих заданные на уровне класса ограничения целостности, сервис должен возвращать код ответа http, соответствующий произошедшей ошибке.
Помимо базового набора, веб-сервис должен поддерживать следующие операции над объектами коллекции:
- Удалить один (любой) объект, значение поля metersAboveSeaLevel которого эквивалентно заданному.
- Вернуть массив объектов, значение поля name которых начинается с заданной подстроки.
- Вернуть массив объектов, значение поля governor которых больше заданного.
- Эти операции должны размещаться на отдельных URL.
Второй веб-сервис должен располагаться на URL /genocide, и реализовывать ряд дополнительных операций, связанных с вызовом API первого сервиса:
- /count/{id1}/{id2}/{id3} : рассчитать суммарное население трёх городов с заданными id
- /move-to-poorest/{id} : переселить всё население города с заданным id в город с наименьшим уровнем жизни
Эти операции также должны размещаться на отдельных URL.
Для разработанной спецификации необходимо сгенерировать интерактивную веб-документацию с помощью Swagger UI. Документация должна содержать описание всех REST API обоих сервисов с текстовым описанием функциональности каждой операции. Созданную веб-документацию необходимо развернуть на сервере helios
Вариант 9265
На основе разработанной в рамках лабораторной работы #1 спецификации реализовать два веб-сервиса и использующее их API клиентское приложение.
Требования к реализации и развёртыванию сервисов:
- Первый ("вызываемый") веб-сервис должен быть реализован на фреймворке Spring MVC REST и развёрнут в окружении под управлением сервера приложений Jetty.
- Второй веб-сервис должен быть реализован на фреймворке JAX-RS, развёрнут в окружении под управлением сервера приложений WildFly и вызывать REST API первого сервиса.
- Для обоих сервисов необходимо реализовать все функции, задокументированные в API, в строгом соответствии со спецификацией!
- Доступ к обоим сервисам должен быть реализован с по протоколу https с самоподписанным сертификатом сервера. Доступ к сервисам посредством http без шифрования должен быть запрещён.
Требования к клиентскому приложению:
- Клиентское приложение может быть написано на любом веб-фреймворке, который можно запустить на сервере helios.
- Приложение должно обеспечить полный набор возможностей, предоставляемых API обоих сервисов -- включая сортировку, фильтрацию и постраничный вывод элементов коллекции.
- Приложение должно преобразовывать передаваемые сервисами данные в человеко-читаемый вид -- параграф текста, таблицу и т.д.
- Клиентское приложение должно информировать пользователя об ошибках, возникающих на стороне сервисов, в частности, о том, что сервису были отправлены невалиданые данные.
В качестве усложнения добавлен hateoas 💀
Вариант 5050
Переработать веб-сервисы из лабораторной работы #2 таким образом, чтобы они реализовывали основные концепции микросервисной архитектуры. Для этого внести в оба сервиса -- "вызываемый" и "вызывающий" перечисленные ниже изменения.
Изменения в "вызываемом" сервисе:
- Разделить приложение на два модуля -- веб-приложение с веб-сервисом и EJB-jar с бизнес-компонентами.
- Переместить всю логику из класса сервиса в Stateless EJB. В классе сервиса оставить только обращение к методам бизнес-интерфейса. EJB-компонент должен быть доступен удалённо (иметь Remote-интерфейс).
- Сформировать на уровне сервера приложений пул компонентов EJB настраиваемой мощности, динамически расширяемый при увеличении нагрузки.
- Установить ПО Consul и настроить Service Discovery с его помощью. Сервис должен регистрироваться в Service Discovery в момент запуска.
Изменения в "вызывающем" сервисе:
- Переработать сервис, обеспечив возможность его развёртывания на платформе Spring Cloud.
- Использовать все основные компоненты архитектуры Spring Cloud: Config Service, Load Balancer, Service Discovery.
- В качестве Service Discovery использовать Eureka.
- В качестве балансировщика нагрузки использовать Ribbon.
- Все запросы к сервисам должны прокироваться через API Gateway. В качестве API Gateway использовать Zuul Proxy.
Оба веб-сервиса и клиентское приложение должны сохранить полную совместимость с API, реализованными в рамках предыдущих лабораторных работ.
Вариант 7070
Переработать сервисы из лабораторной работы #3 следующим образом:
- Второй ("вызывающий") сервис переписать в соответствии с требованиями протокола SOAP.
- Развернуть переработанный сервис на сервере приложений по собственному выбору.
- Оставшийся сервис не модифицировать, не менять его API, протокол и используемый сервер приложений.
- Установить и сконфигурировать на сервере Helios программное обеспечение Mule ESB.
- Настроить интеграцию двух сервисов с использованием установленного программного обеспечения.
- Реализовать дополнительную REST-"прослойку", обеспечивающую возможность доступа к переработанному сервису клиентского приложения без необходимости его модификации Никакой дополнительной логики, помимо вызовов SOAP-сервиса, разработанная REST-прослойка содержать не должна.