Для более четкого понимания особенностей архитектуры REST рассмотрим понятие веб-приложений и их целевое назначение. Веб-приложение или, как его ещё называют веб-сервис, представляет собой программный модуль, который используется для решения единичных или комплексных задач в сети. Основными плюсами веб-приложений является незначительная связанность между собой, легкость интеграции и возможность переиспользования компонентов приложения. Веб-сервисы могут быть написаны на различной архитектуре, но в последнее время особенную популярность приобрела архитектура REST.
Аббревиатура REST (Representational state transfer, передача состояния представления) была впервые использована в 2000 году Роем Филдингом в своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур»[1]. Филдинг описал систему, при которой каждый запрос клиента к серверу несет в себе исчерпывающую информацию об ожидаемом ответе сервера, а также серверу не обязательно хранить информацию о состоянии клиента. Системы, которые работают на основе архитектуры REST и отвечают ее требованиям, называют Restful системами.
При разработке веб-приложения, работающего на архитектуре REST используются следующие основные принципы:
- Использование HTTP-методов
- Нет возможности сохранить состояние
- Данные предоставляются в URL в структуре, аналогичной структуре каталогов
В стандартной ситуации архитектура REST является простым и хорошо документированным инструментом управления информацией: каждая единица информации однозначно определяется идентификатором, имеющим строго заданный формат. При использовании HTTP-методов создается структура URL-адресов, а передавать данные принято в первозданном виде, в формате JSON, так как его структура «ключ:значение» позволяет легко оперировать данными как в исполняемом коде на сервере, так и в клиентских приложениях, но сама архитектура REST не предполагает явных ограничений для представления данных[2].
Каждой единице информации в REST дается однозначное определение в системе URL–адресов, это значит, что адрес и является первичным ключом для единицы информации. Например, для каталога книг по авторам для получения списка книг автора с идентификатором равным 2, URL адрес будет выглядеть как /author/2, а для десятой книги этого автора — /author/2/book/10.
Именно это и подразумевается под строго заданным форматом данных. При этом формат данных по полученному адресу /author/2/book/10 не имеет никакого значения – это может быть и сама книга в вид файла формата *.doc, и фото ее обложки, и ссылка на статью об этой книге в интернет-библиотеке.
Управление информации в данном сервисе целиком и полностью базируется на протоколе передачи данных HTTP и его методах: GET (получить), PUT (добавить, заменить), POST (добавить, изменить), DELETE (удалить). Таким образом, в архитектуре доступы действия CRUD (Create, Read, Update, Delete) и они могут выполняться как с использованием всех 4-х программ, так и на основе только GET и POST[3].
Для большей наглядности можно рассмотреть пример использования архитектуры REST для создания веб-приложения.
- GET /author/ — получить список всех авторов в Базе Данных приложения
- GET /author/10/ — получить информацию об авторе с идентификатором 10
- POST /author/ — добавить книгу (данные должны быть отправлены в теле HTTP-запроса)
- PUT /author/10 – изменить информацию об авторе с идентификатором 10 (данные должны быть отправлены в теле HTTP-запроса)
- DELETE /author/10 – удалить информацию об авторе с идентификатором 10
Для серверного приложения, построенного на принципах REST важно получить запрос, который несет в себе информацию об ожидаемом ответе сервера, такой информацией могут быть заголовки HTTP-запроса, headers, в которых будут указаны формат тела запроса, ожидаемый формат ответа для клиента, язык системы, информация о браузере и другое. В свою очередь, сервер укажет в ответе заголовки с аналогичной информацией о теле ответа и информацией о коде состояния. Эти коды делят на информационные, успешные, сигнал о перенаправлении, ошибки клиента и ошибки сервера[4].
Пример заголовков ответа сервера на GET-запрос:
GET / HTTP/1.1
Host: helloworld.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Charset: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Заключение
Основным преимуществом архитектуры REST является простота её использования. Цель и функции поступившего запроса можно определить сразу по его виду и нет необходимости разбираться в форматах в отличие от SOAP и XML. Данные передаются без применения дополнительных слоев, поэтому REST считается менее ресурсоемким и, следовательно, более производительным, поскольку не надо приводить запрос в читаемый формат.
Основным преимуществом архитектуры является простота внедрения в любой проект, будь то веб-сайт, приложения для мобильных устройств или программа для настольных компьютеров.
Архитектура REST – инструмент, благодаря которому задача создания интерфейса программы становится значительно проще. Конечно, при решении реальных задач по разработке возникает необходимость предусмотреть возможность защиты приложений от несанкционированного доступа, чтобы каждый не мог получить к доступ к информации и возможность изменять ее, данную проблему принято решать использованием HTTP-Authentication, JSON Web Token или других сессий различного типа.
Библиографический список
- Архитектура REST // Хабрахабр. URL: https://habrahabr.ru/post/38730/ (дата обращения: 20.02.2019).
- HTTP Authentication: Basic and Digest Access Authentication // The Internet Engineering Task Force. URL: https://tools.ietf.org/html/rfc2617 (дата обращения: 21.02.2019).
- The OAuth 2.0 Authorization Framework // The Internet Engineering Task Force. URL: https://tools.ietf.org/html/rfc6749 (дата обращения: 21.02.2019).
- Hypertext Transfer Protocol — HTTP/1.1. URL:https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (дата обращения: 21.02.2019).
Количество просмотров публикации: Please wait