ЛР3_АИС_МО417_ИбрагимоваРахимоваСтепановаШакиров

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ФАКУЛЬТЕТ ИНФОРМАТИКИ И РОБОТОТЕХНИКИ

КАФЕДРА ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ

Отчёт по лабораторной работе №3

«Разработка RESTful веб-сервиса»

по предмету: «Администрирование информационных систем»

Выполнили:

студенты группы МО-417

Ибрагимова К.Б. Рахимова А.М.

Степанова Д.Д. Шакиров А.Р.

Проверил:

Сазонова Е. Ю.

Уфа 2021

Цель работы

Разработать RESTful веб-приложение на основе созданной ранее ORM модели базы данных.

Задание

1. Ознакомиться с протоколом HTTP.

2. Ознакомиться с понятием REST API.

3. Спроектировать REST API для серверной части приложения.

4. Реализовать RESTful веб-приложение.

5. Протестировать RESTful приложение.

Теоретическая часть

1. HyperText Transfer Protocol

HTTP — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.

Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

• Потребителей (клиентов), которые инициируют соединение и посылают запрос.

• Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом.

Сервер может использовать любые методы, не существует обязательных методов для сервера или клиента.

Рассмотрим следующие методы:

• GET – ииспользуется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.

• POST – пприменяется для передачи пользовательских данных заданному ресурсу. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты.

• PUT – применяется для загрузки содержимого запроса на указанный в запросе URI. Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

• DELETE – удаляет указанный ресурс.

Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Код	Класс	Назначение
1xx	Информационный	Информирование о процессе передачи. В HTTP/1.0 — сообщения с такими кодами должны игнорироваться. В HTTP/1.1 — клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
2xx	Успех	Информирование о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
3xx	Перенаправление	Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по-другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.
4xx	Ошибка клиента	Указание ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
5xx	Ошибка сервера	Информирование о случаях неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

2. REST API

API — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.

Web API – используется в веб-разработке. Содержит, как правило, определённый набор HTTP-запросов, а также определение структуры HTTP-ответов, для выражения которых используют XML− или JSON−формат.

Web API является практически синонимом для веб-службы, хотя в последнее время за счёт тенденции Web 2.0 осуществлён переход от SOAP к REST типу коммуникации. Веб-интерфейсы, обеспечивающие сочетание нескольких сервисов в новых приложениях, известны как гибридные.

REST — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Другими словами, REST — это набор правил о том, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы.

В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса.

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful». Не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, а не протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.

Понятие URI – система унифицированных адресов электронных ресурсов, или единообразный определитель местонахождения ресурса (файла). Используется как стандарт записи ссылок на объекты в Интернете (Гипертекстовые ссылки во «всемирной паутине» www).

Для обозначения электронного адреса используют аббревиатуру «URL» по ГОСТ Р 7.0.5-2008.

Клиент-серверное взаимодействие – клиенты и серверы обмениваются сообщениями в шаблоне запрос-ответ. Клиент отправляет запрос, а сервер возвращает ответ. Этот обмен сообщениями является примером межпроцессного взаимодействия. Для взаимодействия компьютеры должны иметь общий язык, и они должны следовать правилам, чтобы и клиент, и сервер знали, чего ожидать. Язык и правила общения определены в протоколе связи. Все протоколы клиент-серверной модели работают на уровне приложений. Протокол прикладного уровня определяет основные шаблоны диалога. Чтобы ещё больше формализовать обмен данными, сервер может реализовать интерфейс прикладного программирования (API).

Сервер может получать запросы от множества различных клиентов за короткий период времени. Компьютер может выполнять только ограниченное количество задач в любой момент и полагается на систему планирования для определения приоритетов входящих запросов от клиентов для их удовлетворения. Чтобы предотвратить злоупотребления и максимизировать доступность серверное программное обеспечение может ограничивать доступность для клиентов. Атаки типа «отказ в обслуживании» используют обязанности сервера обрабатывать запросы, такие атаки действуют путем перегрузки сервера чрезмерной частотой запросов. Шифрование следует применять, если между клиентом и сервером должна передаваться конфиденциальная информация.

3. Спроектируем REST API для серверной части приложения

При RESTful веб-сервиса определим ресурсы, которые будут доступны и запросы, с помощью которых можно будет работать с данными ресурсами.

На данном этапе определим URI и HTTP-методы, которые будут вызывать разработанные ранее CRUD операции для БД.

Табл. 1 REST API приложения

Метод HTTP	URL	Действие
POST	https://localhost:5001/api​/account​/register	Зарегистрировать нового пользователя
POST	https://localhost:5001/api​/account​/ auth	Сформировать и получить токен аутентификации пользователя
POST	https://localhost:5001/api​/city	Добавить новый город
POST	https://localhost:5001/api​/friendship	Создать «дружбу»
POST	https://localhost:5001/api​/message	Добавить сообщение
POST	https://localhost:5001/api​/person	Создать профиль пользователя
POST	https://localhost:5001/api​/user	Создать пользователя
GET	https://localhost:5001/api​/city	Получить список городов
GET	https://localhost:5001/api​/city​/{id}	Получить город по id
GET	https://localhost:5001/api​/country	Получить список стран
GET	https://localhost:5001/api​/country​/{id}	Получить страну по id
GET	https://localhost:5001/api​/friendship	Получить список отношений «дружба»
GET	https://localhost:5001/api​/friendship​/{id}	Получить список друзей (подписок) по id
GET	https://localhost:5001/api​/gender	Получить список гендеров
GET	https://localhost:5001/api​/gender​/{id}	Получить гендер по id
GET	https://localhost:5001/api​/message [from={id}][&][to={id}]	Получить список сообщений с фильтрами по отправителю, получателю.
GET	https://localhost:5001/api​/message​/{id}	Получить сообщение по id
GET	https://localhost:5001/api​/person	Получить список профилей пользователей
GET	https://localhost:5001/api​/person​/{id}	Получить профиль пользователя по id
GET	https://localhost:5001/api​/user	Получить список пользователей
GET	https://localhost:5001/api​/user​/{id}	Получить пользователя по id
PUT	https://localhost:5001/api​/city​/{id}	Редактировать город по id
PUT	https://localhost:5001/api​/person​/{id}	Редактировать профиль пользователя по id
PUT	https://localhost:5001/api​/user​/{id}	Редактировать пользователя по id
DELETE	https://localhost:5001/api/city​/{id}	Удалить город по id
DELETE	https://localhost:5001/api/friendship​/	Удалить отношение «дружба» по паре id
DELETE	https://localhost:5001/api/message​/{id}	Удалить сообщение по id
DELETE	https://localhost:5001/api/user​/{id}	Удалить пользователя по id

4. Протестируем RESTful приложение

Для тестирования был выбран набор инструментов для тестирования API — Postman. Он является средой разработки для создания, тестирования, контроля и публикации API-документации. Назначение Postman — тестирование отправки запросов с клиента на сервер и получения ответа от сервера.

Проведем тестирование метода GET на примере сущности Сообщений.

Рисунок 1. Работа запроса на получение сообщений, получатель которых пользователь с id=2

Проведем тестирование метода POST на примере сущности Город.

Рисунок 2. Работа запроса на добавление города в страну с id=1

Проведем тестирование метода PUT на примере сущности Профиль пользователя.

Рисунок 3. Работа запроса на редактирование имени в профиле пользователя

Проведем тестирование метода DELETE на примере сущности Город.

Рисунок 4. Проверка запроса на удаление города с id=1

Вывод

В ходе выполнения лабораторной работы, было разработано RESTful веб-приложение на основе созданной ранее ORM модели базы данных.