В прошлом уроке вы рассмотрели один из стилей API — SOAP. В этом уроке рассмотрим самый популярный на данный момент стиль — REST.
Айгуль
Теперь можем приступить к REST!
Даня
О, от rest я бы сейчас не отказался 😬
Айгуль
Я о стиле взаимодействия…
Даня
Понял. Принял. Слушаю 🙃
Стиль REST
REST — Representational State Transfer (Передача репрезентативного (самоописываемого) состояния) — это архитектурный стиль, описывающий ограничения для проектирования слабо связанных приложений, использующих протокол HTTP (HTTPS) для передачи данных. API, соответствующий ограничениям стиля REST, называют RESTful или просто REST API.
REST использует для проектирования систем все те ограничения и соглашения, которые свойственны сети Интернет, а значит, они проверены временем.
Приложения могут через REST API отправлять друг другу сообщения (HTTP-запросы и ответы) в форматах XML, JSON или в виде простого текста, а через SOAP API — только XML-сообщения. С элементами HTTP-запроса и HTTP-ответа вы познакомились в этом спринте.
REST API является более популярным стилем API, чем SOAP API, потому что он значительно проще в разработке.
Принципы REST API
REST описывает принципы проектирования приложений, множество из которых — это ограничения протокола HTTP, с которыми вы уже знакомы:
Не хранить состояние
Клиент и сервер должны взаимодействовать без хранения состояния (stateless).
Использовать кэширование данных
Кэширование может выполняться как на стороне клиента, так и на стороне API. Кэширование позволит увеличить производительность за счёт использования сохранённых ранее данных.
Проектировать ресурсы (существительные), а не методы или операции (глаголы).
При использовании REST и системному аналитику, и разработчику важно думать о приложении с точки зрения ресурсов, то есть руководствоваться тем, какие ресурсы вовлечены во взаимодействие, и как эти ресурсы определяют операции, которые можно над ними совершать.
Использовать унифицированный интерфейс (uniform interface)
Все ресурсы должны иметь одинаковый, унифицированный интерфейс, который может быть использован для выполнения операций над ресурсом. Унифицированный HTTP-интерфейс определяет CRUD-операции для создания, чтения, обновления и удаления ресурсов в виде HTTP-методов POST, GET, PUT, DELETE. Иными словами, HTTP-запросы должны включать уже известные вам HTTP-методы.
Использовать коды состояния (status code)
HTTP-ответы должны включать также известные вам коды состояний, например, 200 OK, 400 Bad Request, 502 Bad Gateway.
Разберём подробнее три первых принципа.
Хранение состояния
Состояние (state) — это информация, которая используется экземпляром клиентского приложения (приложения, расположенного на клиенте) для его работы.
Представьте, что вы открыли заинтересовавшее вас веб-приложение магазина на личном ноутбуке. В этот момент ваш ноутбук запустил экземпляр веб-приложения магазина и создал его состояние.
Вы решили пока не регистрироваться, но посмотрели каталог магазина и положили несколько товаров в корзину. При добавлении товаров в корзину состояние вашего экземпляра приложения было обновлено.
Теперь представьте, что вы решили открыть веб-приложение того же самого магазина на рабочем компьютере. В этот момент ваш рабочий компьютер запустил другой экземпляр веб-приложения магазина и создал его состояние.
Вы не увидите добавленные вами на ноутбуке товары в корзине, потому что состояния разных экземпляров ничего не знают друг о друге. Они сохраняются на разных клиентских устройствах, а не на сервере.
Можно предположить, что веб-приложение магазина спроектировано в соответствии с ограничениями REST API, потому что его сервер не хранит состояние (stateless server). Всю информацию о состоянии хранит клиент (stateful client). API в таком случае так же не хранит состояния приложений.
Кэширование
Каждый ответ сервера обязан содержать пометку, можно ли кэшировать содержимое ответа. Кэширование позволяет увеличить производительность API за счёт использования сохранённых ранее данных. Кэширование может выполняться как на стороне клиента, так и на стороне API.
Если кэширование выполняется на стороне клиента, это значит, что необходимо предоставить дружественные к кэшированию ответы API.
Например, пользователь на клиенте открыл страницу 27 книги 123. В ответе сервера было указано, что кэширование на стороне клиента разрешено. Если пользователь обновит страницу, то клиент может не отправлять запрос на повторное открытие той же страницы, а открыть ту страницу, которая сохранена в кэше.
Кэширование на стороне клиента может выполняться различными способами, например, временное кэширование в указанный промежуток времени, или HTTP кэширование. Преимуществом второго типа кэширования является то, что за актуальность сохраненных данных отвечает сам протокол.
Кэширование на стороне API предполагает хранение ответов сервера в кэше API без необходимости вызова бэкенда. В этом случае API может играть роль клиента для сервера, полагаясь на HTTP кэширование, то есть на протокол. Либо альтернативный вариант реализации — это актуализация данных путем отправления запросов на сервер через заданные промежутки времени.
Кэшировать можно не только позитивные ответы (с кодом 2xx), но и негативные, что позволит избежать многочисленных ненужных запросов на сервер.
Системный аналитик может встретить реализацию кэширования, основанного на времени, в виде заголовка:
If-Unmodified-Since в HTTP-запросах
Last-Modified в HTTP-ответах.
Ресурсы
Участники взаимодействия (клиент, API, сервер) обмениваются не самими ресурсами (веб-страницы, изображения, видео), а их представлениями.
Процесс преобразования ресурса в представление в соответствии с определённым набором правил называется сериализацией (serialization). Правила сериализации описаны, например, стилями представления данных JSON и XML.
Процесс преобразования представления в ресурс называется десериализацией.
Представление ресурса состоит из:
непосредственно данных;
метаданных, описывающих данные;
гиперссылки (URL).
Ресурс должен иметь уникальный постоянный идентификатор (URL), то есть идентификатор не может измениться за время обмена данными или в результате изменения его состояния. Если ресурсу присваивается другой идентификатор, сервер обязан сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.
Например, книга, доступная под вторым номером, будет иметь идентификатор /books/2, а 27-я страница в этой книге — /books/2/pages/27
Системному аналитику при использовании REST важно думать о приложении с точки зрения ресурсов. То есть в первую очередь необходимо понять то, какие ресурсы вовлечены во взаимодействие, продумав все возможные варианты, а во вторую очередь продумывать, какие операции можно совершить с этими ресурсами.
Сравнение стилей SOAP и REST
REST API и SOAP API часто сравнивают друг с другом:
Сложность реализации
Сервисы, реализованные с помощью REST, считаются “лёгкими” для реализации, сервисы SOAP считаются более “тяжёлыми”.
Структура данных
Сервисы SOAP, как правило, имеют жёсткую, предопределённую и строго формализованную структуру и предоставляют сложные структурированные данные.
Сервисы REST обычно являются более порционными (обслуживая узкие запросы) и обслуживают небольшие структуры данных.
Размер сообщений
Сообщения SOAP содержат много метаданных и поддерживают только подробные XML-структуры для запросов и ответов. Кроме того, из-за большого размера сервисы SOAP считаются сложными как для отправителей, так и для поставщиков.
Сервисы REST разбивают свои структуры данных на необходимые элементы. Однако REST так же, руководствуясь принципом единообразия интерфейса, может передать огромное количество метаданных о состоянии ресура и возможных операциях, поэтому в случае REST это зависит от конкретной реализации.
Используемые протоколы
SOAP может быть реализован на базе многих протоколов, включая HTTP, TCP, UDP и SMTP.
REST ограничен только HTTP, но он под него и оптимизирован: REST может в полной мере использовать его функции кэширования.
Сфера применения
SOAP хорошо подходит для приложений, работающих в корпоративной сети благодаря своей жёсткой структуре, а также возможностям безопасности и авторизации. SOAP удобен для финансовых транзакций или при наличии строгих формальных требований на программное обеспечение между API и клиентом. SOAP часто используется для интеграции с корпоративными партнерами.
REST хорошо подходит для API, предназначенных для широкого использования многими клиентами.
Подведём итоги
REST предлагает концепцию построения приложения, при которой каждый запрос клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера, и сервер не обязан сохранять информацию о состоянии клиента.
Ключевая абстракция данных в REST — это ресурс. Так как ресурс — это абстрактное понятие, он сам по себе не передается. Сервер и клиент обмениваются их представлениями.
REST API выполняет операции с ресурсами. Такие операции соответствуют HTTP-методам. Использовать другие методы в REST API, кроме как HTTP-методы, нельзя.
Принципы REST:
не хранить состояние,
проектировать ресурсы (существительные), а не методы или операции (глаголы),
использовать кэширование данных,
использовать унифицированный интерфейс и коды состояния
REST хорошо подходит для API, предназначенных для широкого использования многими клиентами.