ИСПОЛЬЗОВАНИЕ АРХИТЕКТУРНОГО СТИЛЯ ВЗАИМОДЕЙСТВИЯ REST API В МОБИЛЬНОМ ПРИЛОЖЕНИИ

ИСПОЛЬЗОВАНИЕ АРХИТЕКТУРНОГО СТИЛЯ ВЗАИМОДЕЙСТВИЯ REST API В МОБИЛЬНОМ ПРИЛОЖЕНИИ

Веркошанский Денис Валерьевич

студент Воронежского Государственного Технического Университета,

РФ, г. Воронеж

Мешков Александр Анатольевич

студент Воронежского Государственного Технического Университета,

РФ, г. Воронеж

Агаджанян Артур Борисович

студент Воронежского Государственного Технического Университета,

РФ, г. Воронеж

АННОТАЦИЯ

В статье рассматривается использовании архитектурного стиля взаимодействия REST API в мобильном приложении, выделены группы архитектурных ограничений. Выявлены преимущества и недостатки архитектуры REST, а также рассмотрены стандартные методы для взаимодействия с объектами.

Ключевые слова: RESTfull, REST, API, архитектурные ограничения.

С каждым годом API-интерфейсы появляются в сферах человеческой деятельности, создание новых API облегчает работу и жизнь людей. На данный момент API оказывает большое влияние в сферах бизнеса, социальных сетей, метеоданных и медицины.

Когда несколько отдельных приложений нуждаются в посреднике, для обмена данными между внутренними и внешними программными функциями друг с другом, приходится создавать мосты взаимодействия, такими мостами выступают программные интерфейсы приложений (API). Для масштабной и быстрой интеграции приложений используются различные протоколы, которые определяют синтаксис передаваемых объектов. Данные протоколы образуют архитектуру API.

Большая часть рынка мобильных устройств реализованы под операционные системы Android, IOS, Microsoft. Разработка мобильных приложений имеет свои особенности. Основной причиной создания API является многопользовательское условие мобильного приложения. Для получения одним пользователем информации от другого или о другом между ними должен произойти обмен информации, а также хранение информации на телефоне слишком ненадежно. Данные задачи решаются за счет централизации бизнес-логики, а для доступа к ней разрабатывается RESTfull API.

Также API предоставляет большие возможности для разработчиков, которые хотят добавить определенный функционал в свое приложение, но вникать в устройство работы системы долго и сложно. К примеру, для реализации вывода погодных условий пользователю, разработчику необходимо вызвать нужный API-метод, не вникая в работу метеостанций.

Обмен данными между мобильными клиентами и серверами осуществляется по архитектурному стилю взаимодействия компонентов распределенного приложения в сети по модели клиент-сервер - Representational State Transfer (REST). При этом вызов удаленных процедур осуществляется по средствам обычного HTTP-запроса, необходимые данные при этом передаются в качестве параметров запроса.

Особенности архитектурного стиля:

• Сущности должны быть связаны между собой.
• Обязательное использование стандартных методов для изменения и чтения данных
• Необходимо чтобы поддерживались нескольких типов ресурсов.
• Осуществление взаимодействия должно происходить без состояния.
• Каждый объект обязан иметь уникальный идентификатор – URI.

Система, соответствующая требованиям RESTfull, должна удовлетворять архитектурным ограничениям, которые выделил Филдинг:

• Клиент-сервер. Сеть должна состоять из клиентов и серверов.
• Отсутствие состояния. Сервер не  хранит информацию о состоянии клиента, клиент не хранит информацию о состоянии сервера в периодах между запросами. Клиент и сервер могут не отслеживать друг друга. Запросы рассматриваются как самостоятельные.
• Кэширование. Серверный ответ помечается кэшируемым или некэшируемым.
• Единообразие интерфейса. Между серверами и клиентами должен существовать общий язык, который позволяет каждой части быть заменяемой или изменяемой, без нарушения целостности системы.
• Код по требованию. Сервер отправляет клиенту исполняемый код. Это ограничение является опциональным
• Идентификация ресурсов.
• Самодокументируемые сообщения.
• HATEOAS. RESTfull серверы и клиенты не должны полагаться на запрограммированный интерфейс. Вместо этого сервер отправляет набор URL. Этот набор представляет клиенту варианты перехода между состояниями, из этих состояний клиент может выбирать.
•  Клиенту известна(доступна) только одна точка входа на сервер. Дальнейшее взаимодействие обеспечиваются сервером.
• Многоуровневость системы. Сервера в RESTfull могут располагаться на разных уровнях, из-за этого все сервера обращаются только к серверам ближайших уровней и не связаны запросами с другими.

Если в приложении соблюдаются все необходимые RESTfull требования к реализации, то приложение имеет следующие положительные качества:

• Надёжность системы (так как информация о состоянии клиента, которая может быть потеряна, не сохраняется).
• Использую кэш достигается хорошая производительность.
• Масштабируемость. (Способность расширять приложение)
• Прозрачная система взаимодействия.
• Обслуживание сети.
• Простота интерфейсов.
• Портативность компонентов.
• Гибкая система позволяет легко вносить изменения.
• Способность обработки.

Для взаимодействия с объектами в системе REST используются стандартные методы HTTP такие как: GET, PUT, POST, DELETE. GET позволяет получить ресурс или их коллекцию, POST создать, PUT обновить и DELETE удалить.

Но в использовании архитектуры REST не все так однозначно и в ней, как и во всех архитектурах есть свои минусы:

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

Список литературы:

1. Fielding R.T. "Representational State Transfer (REST)". Doctoral dissertation. University of California. 2000.