REST API: что это и как использовать

API (Application Programming Interface) — это интерфейс программирования приложений, который определяет, как программы могут взаимодействовать друг с другом. Например, как онлайн-магазину обращаться в CRM, чтобы показывать на сайте актуальное количество товара в наличии. Главное преимущество, которое выделяет REST API на фоне остальных видов API, – использование стандартных HTTP-запросов для обмена данными. Это делает его понятным и удобным для разработчиков, а также обеспечивает совместимость между системами и платформами.

REST (Representational State Transfer) — это архитектурный стиль для создания распределенных систем. Он описывает, как сервер и клиент работают друг с другом. Его любят за гибкость и масштабируемость. Благодаря ему разработчики могут сократить время от начала разработки до выхода конечного продукта на рынок. Сервисы, реализованные по его правилам, называются термином «RESTful».

В REST API есть шесть принципов проектирования интерфейса приложения. Пять из них обязательные, последний — опциональный.

Модель работы клиент-сервер

Что означает

Клиент и сервер разделены и функционируют независимо. Под клиентом понимается программа, которая отправляет запрос на сервер, чтобы получить доступ к тем или иным сведениям. Например, при переходе со страницы с результатами поисковой выдачи к этой статье, ваш браузер обратился к серверу Cloud.ru и получил ответ в виде страницы, которую вы сейчас видите.

Как работает

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

Если вы захотите модернизировать логику работы сервера, то на приложении это никак не скажется. Пользователь даже не узнает, что были какие-то изменения, до тех пор, пока все элементы системы функционируют нормально, то есть, понимают друг друга. А если вы решили развивать бизнес и запустить десктопную версию, то нужно написать новую клиентскую программу, а на сервере менять ничего не придется.

Какие плюсы

При таком подходе код запроса остается у пользователя, а код доступа к данным — на сервере.

Масштабируемость

Данная модель хороша своей масштабируемостью путем добавления дополнительных серверов или ресурсов. Это обеспечивает более высокую производительность и надежность системы.

Централизованное управление

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

Безопасность

Сервер обрабатывает запросы от клиентов, что позволяет реализовать дополнительные меры безопасности, такие как аутентификация, авторизация и шифрование данных. Это помогает защитить систему от несанкционированного доступа и атак.

Какие минусы

Зависимость от бесперебойности работы серверов

Клиент-серверная архитектура требует стабильного и быстрого интернет-соединения, чтобы обеспечить эффективность работы. Клиент[ВШ1]  не сможет работать, если упадет сервер или перестанет работать база данных (БД).

Необходимость в системном администраторе

Нужен отдельный специалист, который будет следить за серверами приложения и БД.

Сложность реализации и настройки

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

Отсутствие состояния (stateless)

Что означает

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

Как работает

Например, есть сервис погоды в любой точке мира. Вам интересен прогноз в Пекине на завтра, вы отправляете соответствующее обращение. Если потом нужно узнать о погоде на послезавтра, то придется составлять новый запрос, вновь указывая место и дату.

Какие плюсы

Принцип stateless уменьшает нагрузку на сервер, что особенно важно, если к нему подключено много клиентов.

Масштабируемость

Stateless-подход позволяет разработчикам создавать системы, которые могут легко масштабироваться горизонтально, то есть путем добавления дополнительных серверов или ресурсов. Это обеспечивает более высокую производительность и надежность системы.

Эффективность

Принцип stateless исключает необходимость хранить информацию о состоянии клиента на сервере. Это упрощает обработку запросов и ускоряет работу системы.

Гибкость и удобство

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

Какие минусы

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

Дополнительная нагрузка на сервер при повторяющихся запросах.

Кеширование

Что означает

У каждого ответа сервера должна быть пометка, выполняется кеширование данных или нет. Кеширование встречается на новостных порталах, соцсетях — там, где происходит много однотипных запросов.

Какие плюсы

В этом случае часть данных сохраняется на промежуточном сервере или у клиента.

Повышение производительности

Кеширование позволяет временно хранить данные в памяти, что ускоряет их последующее извлечение и обработку. Это сокращает время отклика API и улучшает общую производительность системы.

Снижение нагрузки на сервер

Благодаря кешированию уменьшается количество запросов к базе данных или другим источникам данных. Это снижает нагрузку на сервер и ускоряет его работу.

Улучшение пользовательского опыта

Быстрое выполнение запросов и снижение времени отклика улучшают пользовательский опыт, делая взаимодействие с API более плавным и эффективным.

Какие минусы

• Устаревание кешированных данных (outdated cache).

• Необходим дополнительный трафик для обновления кеша между узлами.

• Необходимо выделенное пространство в оперативной памяти сервера для хранения кешированных данных.

• Риск проблем с безопасностью, если в кеш попадут конфиденциальные данные.

• Невозможность показа персонализированного контента разным пользователям.

• Кеширование не подходит для динамически генерируемого контента.

Единообразие интерфейса (uniform interface)

Что означает

Интерфейс должен быть унифицированным, чтобы клиент всегда понимал, в каком формате он должен посылать запросы, а сервер — как и в каком виде ему отвечать на них.

Как работает

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

Какие плюсы

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

 Простота использования

Единообразие интерфейса упрощает работу с API, поскольку разработчикам не нужно изучать разные способы взаимодействия с каждым отдельным сервисом. Это ускоряет процесс разработки и уменьшает количество ошибок.

Стандартизация

Единый интерфейс способствует стандартизации процессов и подходов в рамках организации или экосистемы. Это облегчает интеграцию различных систем и компонентов, а также обеспечивает совместимость между различными сервисами.

Обучение и документация

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

Какие минусы

Единообразие интерфейса может иметь обратную сторону медали для разработчиков.

Ограничение гибкости

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

Сложность поддержки

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

Увеличение времени разработки

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

Многоуровневая система

Что означает

Между клиентом и сервером могут находиться дополнительные структуры, например, прокси-сервер (промежуточный сервер) для кеширования, обеспечения безопасности и дополнительной обработки данных. Концепция многоуровневой системы заключается в том, что никто из участников не знает всего пути, по которому проходит запрос — только «соседей» справа и слева.

Как работает

На практике многоуровневая система означает, что ни пользователю, ни прокси неизвестно, к кому он обращается — к серверу напрямую или очередному посреднику. В обратную сторону это тоже работает: элементы цепочки не знают, куда от них уходит ответ.

Какие плюсы

Многоуровневая система позволяет легко менять архитектуру.

Гибкость и масштабируемость

Многоуровневая система позволяет разработчикам легко добавлять, изменять или удалять функции без влияния на другие уровни. Это обеспечивает гибкость в разработке и упрощает процесс масштабирования системы в соответствии с растущими требованиями.

Улучшение безопасности

Разделение функциональности на уровни облегчает реализацию мер безопасности на каждом уровне отдельно. Это помогает предотвратить несанкционированный доступ и повышает общую безопасность системы.

Упрощение тестирования

Благодаря разделению на уровни, тестирование каждого компонента становится более управляемым и эффективным. Разработчики могут тестировать каждый уровень отдельно, что ускоряет процесс разработки и улучшает качество продукта.

Какие минусы

Риск возникновения проблем с совместимостью

При изменении одного из уровней может возникнуть необходимость адаптации других уровней. Это увеличивает риск возникновения ошибок и проблем совместимости, которые могут потребовать дополнительного времени и усилий для решения.

Увеличение времени отклика

Из-за дополнительных уровней обработки запросов время отклика может увеличиться. Это может негативно сказаться на производительности системы, особенно при высоких нагрузках

Сложность реализации

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

Код по требованию

Предыдущие пять принципов считаются обязательными, этот же можно использовать по желанию.

Что означает

Сервер может отправить исходный код клиенту, например, скрипт для запуска видео. А тот запустит его и выполнит запрошенные действия. Таким образом можно передавать целые сценарии.

Какие плюсы

Для клиента это означает дополнительную гибкость, но одновременно может создавать потенциальную угрозу безопасности. Именно поэтому код по требованию — необязательный принцип: его следует применять разумно и в тех ситуациях, когда возможные преимущества перевешивают недостатки. 

Гибкость и масштабируемость

Код по требованию позволяет серверам отправлять клиентам функциональность, которую те могут динамически исполнять.

Обновление без необходимости распространения клиентских приложений

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

Снижение объема избыточности данных

Поскольку клиент может получать только необходимую функциональность или логику, которую следует выполнить, это может снизить объем данных, передаваемых между сервером и клиентом.

Какие минусы

Безопасность.

Исполнение кода, загруженного с сервера, может представлять угрозу безопасности. Особенно, если сервер не надежен или его безопасность была скомпрометирована, это может привести к выполнению вредоносного кода на клиентской стороне.

Совместимость и зависимость от платформы

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

Усложнение отладки и тестирования

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

Чтобы сайт или приложение выполнили запрос, полученный от пользователя, используются разные способы взаимодействия. Обычно для коммуникации между клиентом и сервером хватает пяти основных методов. Рассмотрим каждый на примере. Допустим, у вас своя пиццерия, где доставку на дом можно заказать через сайт.

POST

POST — это метод для создания новых данных на сервере. Он считается независимым: его можно вызвать нужное количество раз, создавая при этом новые записи.

Как работает метод на примере пиццерии:

1. Покупатель оформляет заказ на сайте.

2. С помощью запроса POST информация о пользователе (ФИО, адрес доставки, телефон, выбранные позиции из меню) отправляется на сервер.

3. Там создается новый заказ с уникальным идентификатором.

4. Клиенту приходит подтверждение: сообщение, что заказ оформлен и пиццу начали готовить.

PUT

Метод используется для полного обновления данных, он передает весь объект с новой или обновленной информацией и начинает работать после POST.

Как происходит процесс в пиццерии: 

1. Пиццерия приступила к приготовлению.

2. Но клиент решил, что хочет добавить еще одну пиццу, и изменил заказ.

3. С помощью запроса PUT сервер целиком перезаписывает существующие данные заказа, сохраняя лишь уникальный идентификатор, и обновляет сведения.

DELETE

Предположим, клиент передумал совершать покупку, тогда он может отменить заказ. Тогда на сервер отправляется запрос DELETE — удаление информации.

PATCH

Или же все прошло хорошо: еду приготовили, заказ по-прежнему актуален. Многие интернет-магазины, рестораны, сервисы предлагают отследить маршрут движения курьера на карте. Для корректного отображения сведений будет применяться метод PATCH — частичное изменение данных.

GET

Метод для чтения информации. Он не удаляет и не исправляет сведения, а просто передает их с сервера.

В нашем случае с пиццерией это может выглядеть так:

1. Клиент хочет проверить в личном кабинете текущий статус заказа, для этого будет использован запрос GET.

2. Или же хочет вернуться на страницу каталога, где представлены все доступные позиции в ассортименте заведения, — то же самое.

Информация между пользователем и сервером передается через HTTP-сообщения (или HTTP-request). Они бывают двух видов: запрос и ответ.

Структура запроса

Он отправляется от пользователя к серверу и состоит из обязательных элементов:

• Конечная точка. Она называется endpoint — это адрес, куда должен дойти запрос. Если продолжить пример с пиццерией, то конечной точкой для отправки обращения в службу доставки может являться luchshaya-picceriya.com/orders (здесь и далее адрес выдуман);

• Заголовки. В них содержится дополнительная информация, необходимая для корректной обработки запроса — формат передаваемых данных, спецификация, аутентификационные сведения о пользователе;

• Параметры. Помогают уточнить обращение. Допустим, чтобы посмотреть информацию о конкретном заказе, запрос может выглядеть так: luchshaya-picceriya.com/orders/list?orderId=123456;

• Тело. Содержит параметры, необходимые для обработки — чаще всего в формате JSON. В случае со службой доставки это может быть адрес или телефон покупателя.

Структура ответа

После того как запрос поступил на сервер, тот отправляет ответ, в котором есть заголовок и тело — те сведения, которые нужны клиенту. Эти элементы передаются в формате JSON, иногда в XML. Тело ответа может быть пустым. Еще ответ содержит трехзначный код состояния, указывающий на успешность выполнения обращения. Любой интернет-пользователь сталкивался с ним не раз: «404: Not found», когда страница не найдена, как раз пример такого кода.

Коды состояния ответа делятся на категории в зависимости от первой цифры:

• 1хх — информационные сообщения;

• 2хх — запрос выполнен;

• 3хх — нужно уточнение;

• 4хх — ошибка со стороны клиента;

• 5хх — ошибка на сервере.

REST API применяется на сайтах и в веб-приложениях, корпоративных системах, социальных сетях. Простой пример — кнопка «Поделиться». Ее можно встретить практически на каждом портале, она позволяет разместить информацию со страницы в ленте той или иной соцсети.

Чаще всего REST API актуален в следующих случаях:

• программа в будущем будет масштабироваться;

• у сервера небольшая производительность;

• используется AJAX (обмен информацией между сервером и пользователем в фоновом режиме);

• проект поделен на микросервисы.

Если вашему проекту уже не хватает мощностей на собственном сервере, он быстро растет, то можно перенести его в безопасное и масштабируемое облако. Например, облачный провайдер Cloud.ru предлагает аренду виртуальных машин для развертывания сайтов с оплатой за потребленные ресурсы.

Несмотря на популярность REST, в разработке встречаются и другие подходы. Например, GraphQL — он позволяет установить, какие данные нужны на стороне клиента, и передавать только их. Считается, что этот метод может обеспечить более мощный и гибкий подход к API, но при этом более сложен для разработчиков — особенно тех, у кого нет соответствующего опыта работы.

Иногда в качестве альтернативы REST называют SOAP (Simple Object Access Protocol). Но подобное сравнение не совсем корректно, поскольку REST — это архитектурный style, а SOAP — протокол передачи данных.

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

Данный архитектурный стиль уже много лет не теряет популярности. Это объясняется его преимуществами. Хотя недостатки тоже есть, как у любого другого инструмента.

Плюсы:

• REST API применяет классические HTTP-запросы, поэтому он прост в использовании;

• легкость масштабирования за счет принципа stateless — запросы обрабатываются независимо, поэтому производительность приложения может значительно повышаться без кратного увеличения нагрузки на сервер;

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

Минусы:

• нельзя устанавливать лимит на максимальный размер передаваемых данных;

• из-за принципа stateless могут возникнуть сложности с управлением состояния в некоторых приложениях;

• отсутствует спецификация, поэтому REST не всегда подходит для работы со сложными проектами.

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

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