- Что такое REST
- Принципы REST API
- Обмен сообщениями без хранения состояния
- Клиент-серверная модель
- Единый интерфейс
- Кеширование
- Многоуровневая система
- Код по требованию
- Методы REST API
- Для чего используется REST API
API или Application Programming Interface — это технология, с помощью которой программы общаются друг с другом. Хорошим примером выступает новостной сайт, на котором есть виджет с погодой, где отображается температура, осадки и атмосферное давление в реальном времени. Сайт ничего не знает о погоде, он получает информацию со стороннего ресурса, например, с Gismeteo. Обмен данными происходит через интерфейс API.
Существует несколько типов интерфейса: SOAP, WebSocket, gRPC и GraphQL. Одним из самых распространенных является REST API.
Что такое REST
Это стандарт обмена данными между приложениями — стиль архитектуры, который задает определенные правила создания сервисов. Стандарт применим к разным протоколам, но чаще используется в связке с HTTP.
Аббревиатура расшифровывается как Representational State Transfer — передача репрезентативного состояния, или состояния представления. Расшифровка описывает главную особенность этого стандарта — приложения обмениваются сообщениями без сохранения состояния.
REST API — это структура для разработки программ, которые общаются с другими программами по стандарту Representational State Transfer. Такие программы называются RESTful.
Принципы REST API
Стандарт предъявляет шесть требований к проектированию программного обеспечения:
- обмен сообщениями без хранения состояния;
- клиент-серверная модель;
- единый интерфейс;
- кеширование;
- многоуровневая система;
- код по требованию.
Первые пять являются обязательными, использование последнего остается на усмотрение разработчика RESTful-приложения.
Обмен сообщениями без хранения состояния
Сообщение, которое отправляет клиентский сервис, содержит все необходимые данные для обработки запроса. Серверная часть не хранит информацию между обращениями от одного клиента. Таким образом, каждое сообщение обрабатывается независимо от предыдущих сессий, что делает взаимодействие программ быстрым и надежным.
Преимущества подхода:
- производительность;
- надежность;
- масштабируемость.
Использование архитектуры Representational State Transfer позволяет обрабатывать большое количество клиентских обращений параллельно. Это снижает нагрузку на серверную часть, делает всю систему адаптивной и гибкой. Поскольку каждое сообщение самодостаточно, отказ в одном запросе не влияет на обработку других, что повышает надежность приложения или сервиса.
Сервер легко масштабировать, добавляя дополнительные модули для обработки сообщений без необходимости синхронизации состояния.
Клиент-серверная модель
Клиентская и серверная части работают как отдельные модули и не зависят друг от друга. Такой принцип дает несколько преимуществ:
- простота разработки и поддержки ПО;
- гибкость интерфейса на разных платформах;
- независимое развитие компонентов системы.
При создании программного продукта можно разрабатывать серверную и клиентскую части параллельно, любыми методами и инструментами, необязательно совместимыми. Можно использовать разные языки программирования, в любое время менять технологии и структуру внутри приложений, что не влияет на процесс обмена данными.Также можно добавлять в систему новые компоненты, например, клиентские приложения для разных устройств, без каких-либо изменений на сервере.
Для примера рассмотрим систему организации работы смарт-часов. Клиентская часть этой системы — программное обеспечение на часах, серверная — хранилище данных, модули приема, обработки и отправки сообщений.
Допустим, разработчик системы решает перейти на другое серверное ПО, поменять свойства или конфигурацию. Эти действия не отразятся на работоспособности системы. Переустанавливать или обновлять программное обеспечение на устройстве пользователя не нужно.
По мере развития проекта к тому же серверу можно подключать новые устройства с совершенно другим ПО: умные колонки, чайники, весы или фитнес-браслеты. Разрабатывать нужно только клиентские приложения, серверную часть менять не придется. Достаточно настроить интеграцию по HTTP на стороне клиента.
Единый интерфейс
В веб-разработке каждый компонент приложения является ресурсом, к которому можно получить доступ через уникальный URI — Uniform Resource Identifier. Ресурс — это «цель» HTTP-запроса: изображение, документ или видео.
Принцип единообразия интерфейса означает, что запросы к каждому ресурсу должны быть унифицированы. При добавлении нового ресурса нужно сохранять логику взаимодействия с уже существующими в системе.
Как правило, данные на серверном хранилище имеют один формат, а в клиентскую часть передаются в другом. Для преобразования файлов при передаче приложению обычно используются форматы XML или JSON. Ответы на запросы к новым ресурсам должны приходить в том же виде, что и к старым. Сообщения должны быть информативными: серверу необходимо понимать, какие операции можно совершать с ресурсом, например, разрешены ли операции обновления или удаления.
Кеширование
Мы говорили, что при работе с приложениями RESTful не нужно хранить состояние сообщений. Это помогает оптимизировать производительность системы и уменьшить нагрузку на сервер. Но иногда логика продукта такова, что клиентская часть регулярно запрашивает одни и те же данные. Тогда на стороне серверного обеспечения нужно каждый раз собирать такие данные с нуля, что ведет к обратному эффекту — снижению скорости работы системы и росту нагрузки.
Проблему решает метод кеширования: часть данных сохраняется на промежуточных серверных компонентах или локально в клиентском приложении. Объем кеша не должен быть слишком большим, иначе потребуется увеличение памяти и внедрение механизмов очистки лишней или устаревшей информации. Чтобы регулировать процедуру кеширования, сервер помечает каждый ответ как кешируемый или некешируемый.
Многоуровневая система
Иерархическая структура организации ресурсов предполагает, что клиент общается с сервером не напрямую, а через посредника — прокси.
Многоуровневая система состоит из нескольких посредников, которые можно разделить по уровням безопасности, функциональности, типу обрабатываемых данных или другим критериям. Приложение отправляет сообщение и не знает, от какого компонента серверной части получает ответ. Прокси могут обмениваться запросами друг с другом незаметно для клиентских приложений.
Принцип иерархии ограничивает знание системы о процедурах и операциях одним уровнем. Это обеспечивает надежность, безопасность, устойчивость сервиса и независимость его компонентов. Многоуровневую систему проще масштабировать: добавление, удаление и изменение компонентов не сказывается на работе программы. Распределение задач между посредниками позволяет достичь оптимальной балансировки нагрузки.
Код по требованию
В REST можно временно поменять функциональность клиентского приложения с помощью специально передаваемого кода. Наглядный пример — посетитель интернет-магазина заполняет форму заказа через обратный звонок. На сайте не реализованы механизмы проверки данных в поле ввода. Но для бизнес-логики важно, чтобы номер телефона был указан верно, — иначе менеджер не дозвонится до пользователя и магазин потеряет потенциального покупателя.
Проблема решается с помощью кода по требованию. Клиентское приложение отправляет запрос, в ответ получает скрипт — исполняемый код, который можно выполнить прямо в сервисе.
Методы REST API
Сам по себе стандарт не является протоколом и не имеет конкретных методов. Это архитектурный стиль написания сообщений, который обычно применяют к HTTP / HTTPS — HTTP Secure. При обмене данными действуют стандартные методы протокола HTTP:
- GET — получение;
- POST — создание;
- PUT — обновление;
- DELETE — удаление.
Для чего используется REST API
Для следования стандарту не нужно придерживаться конкретного клиентского стека. HTTP-протокол используется всеми операционными системами и языками программирования. Это открывает широкие возможности применения в разных направлениях, например:
- веб-разработке;
- мобильных приложениях;
- интернете вещей;
- облачных вычислениях.
Representational State Transfer — самый распространенный метод организации взаимодействия программ. С его помощью можно решать проблемы масштабирования, низкой пропускной способности, обмена данными между компонентами микросервисной архитектуры и работы сервисов в условиях нестабильной связи.