Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль или набор принципов взаимодействия компонентов различных систем в интернете. Технология позволяет разработчикам обеспечивать взаимодействие между клиентами и серверами в распределенной сети.
Кратко о REST API
Термин REST впервые использовал Рой Филдинг в 2000 году в своей докторской диссертации «Architectural Styles and the Design of Network-based Software Architectures».
REST API использует стандартные HTTP-методы:
- GET для получения данных;
- POST для публикации данных;
- PUT для обновления данных;
- DELETE для удаления данных.
Методов существует больше, но именно эти четыре необходимы REST API для обмена данными между приложениями. Использование стандартных методов упрощает разработку, облегчая интеграцию и масштабирование приложений.
Основные концепции REST API
REST основывается на принципах, которые делают архитектуру веб-приложений масштабируемой и простой в использовании.
- Stateless. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для его выполнения. Сервер не сохраняет состояние клиента вне запросов.
- Uniform Interface. Интерфейс взаимодействия между клиентом и сервером должен быть единообразным, что упрощает и обобщает взаимодействие.
- Cacheable. Ответы на запросы должны быть по возможности кешированными для увеличения производительности.
- Client-Server. Строгое разделение клиента и сервера позволяет разрабатывать и масштабировать их независимо друг от друга.
Преимущества REST API
- Простота и гибкость. REST API применяет стандартные HTTP-методы, что делает его доступным и удобным для широкого спектра приложений.
- Масштабируемость. Благодаря stateless архитектуре REST API облегчает масштабирование систем. Независимость запросов позволяет увеличивать производительность приложения без значительного увеличения нагрузки на сервера.
- Совместимость и доступность. REST API обеспечивает легкую совместимость и интеграцию между различными платформами и приложениями.
- Кеширование. Поддержка кеширования ответов сервера повышает производительность приложений, что снижает время загрузки и уменьшает нагрузку на сервер.
- Легкость интеграции с веб-службами. REST API упрощает подключение и использование внешних веб-служб, что расширяет функциональность и возможности приложений.
- Эффективность и производительность. Оптимизация данных и запросов способствует уменьшению нагрузки на сеть, благодаря чему повышается общая производительность приложений.
- Межплатформенная разработка. Универсальность REST API облегчает разработку приложений для различных платформ, включая мобильные устройства и IoT, упрощает межплатформенную интеграцию.
Недостатки REST API
Ограниченная безопасность.
Сложность управления состоянием. Stateless архитектура может усложнить управление состоянием в некоторых приложениях.
Как работает REST API
REST API работает на основе запросов и ответов между клиентом и сервером через протокол HTTP.
- Клиент отправляет HTTP-запрос на сервер, который включает в себя метод, например GET, URL и при необходимости тело запроса с данными.
- Сервер обрабатывает запрос, выполняет необходимые действия и отправляет обратно ответ, обычно в формате JSON или XML, включая статус-код (например, 200 для успешного выполнения или 404 для ненайденного ресурса) и запрошенные данные или сообщение об ошибке.
Если объяснять этот процесс простым языком: REST API передает запросы между клиентом (например, вашим компьютером) и сервером в интернете (например, тем, где размещен определенный сайт). Когда вы хотите получить какую-то информацию с сайта (например, открыть страницу), ваш компьютер отправляет запрос на сервер с помощью REST API. Если всё сработало правильно, вы видите нужную страницу, если нет — страницу 404 или другое сообщение об ошибке. Доставляет ответные сообщения тоже REST API.
Безопасность REST API
Для снижения рисков по работе с REST API применяются различные методы обеспечения безопасности, включая аутентификацию (через токены или OAuth), шифрование данных (SSL/TLS для HTTPS-соединений) и контроль доступа (через API ключи или правила доступа). Это позволяет защитить данные и предотвратить неавторизованный доступ.
Где используется REST API
REST API применяется во многих областях от социальных сетей до корпоративных систем. Например, Twitter, Pagelook, Facebook, и Google предоставляют REST API для доступа к своим сервисам, что позволяет разработчикам интегрировать эти платформы со своими приложениями. E-commerce платформы, такие как Shopify, DST Platform и Magento, используют REST API для управления товарами и заказами.
Для чего используют REST API
Архитектура REST API — самое популярное решение для организации взаимодействия между различными программами. Так произошло, поскольку HTTP-протокол реализован во всех языках программирования и всех операционных системах, в отличие от проприетарных протоколов.
Чаще всего REST API применяют:
- Для связи мобильных приложений с серверными.
- Для построения микросервисных серверных приложений. Это архитектурный подход, при котором большие приложения разбиваются на много маленьких частей.
- Для предоставления доступа к программам сторонних разработчиков. Например, Stripe API позволяет программистам встраивать обработку платежей в свои приложения.
Что еще важно знать при работе с REST API
Каждый REST API запрос сообщает о результатах работы числовыми кодами — HTTP-статусами.
Например, редактирование записи на сервере может отработать успешно (код 200), может быть заблокировано по соображениям безопасности (код 401 или 403), а то и вообще сломаться в процессе из-за ошибки сервера (код 500). Цифровые статусы выполнения ошибок — аналог пользовательских сообщений с результатами работы программы.
Также REST API позволяет обмениваться не только текстовой информацией. С помощью этого инструмента можно передавать файлы и данные в специальных форматах: XML, JSON, Protobuf.
Есть и другие способы построения API-систем, например: JSON-RPC, XML-RPC и GraphQL. Но пока REST остается самым популярным и востребованным инструментом для построения взаимодействий между удаленными приложениями.
За годы использования REST разработчики компании DST Global накопили много практик по разработке API, балансировке и обработке API HTTP-трафика на облачных и железных серверах, а также в приложениях, которые работают в контейнерах. Так что REST API — пример решения, которое подходят для почти любых систем.
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Во-вторых, принципы REST мы часто применяем в жизни. Они очень полезны для осмысления. Кэширование, STATELESS и STATEFUL, клиент-серверная модель или код по требованию — это те вещи, которые аналитику полезно знать для понимания.
Третье — это то, что парадигма REST помогает нам выявить и определить важнейшие свойства архитектуры — масштабируемость, производительность и т.д.
Кто-то проектирует архитектуру сервиса, кто-то только формирует API. Наиболее часто аналитик готовит описание REST-сервиса с помощью каких-нибудь формализованных языков (например, Swagger или JSON-схемы).
Если не рассматривать описание формализованных языков, то остается описание структуры запросов/ответов, описание возможных ошибок, проектирование внутренней логики сервиса и того, что он делает.
Также можно упомянуть SOAP UI и Swagger UI. Кстати, Swagger — это не только некоторый язык формального описания API, но ещё и редактор, с помощью которого можно вызывать реальные сервисы.
Какую последовательность действий можно посоветовать?
— Найти общедоступное API;
— Выбрать одну из утилит (я бы рекомендовал начать с Postman);
— Тренироваться.
На одном из проектов мы действовали оперативно: начинали с самого минималистичного варианта, говорили команде, что будем экспериментировать. И затем с фидбеком от команды оперативно перейдём к тому формату требований, который всех устраивает.
Если говорить про описание API, то это могут быть разные формальные языки. Описание REST API с помощью Swagger, описание транспортов/протоколов с помощью JSON-схемы, с помощью XSD + WSDL, если это SOAP-сервисы.
Ещё аналитик проектирует взаимодействие между системами или сервисами. Очень часто это визуализируют с помощью диаграммы последовательности (sequence diagram). Также можно использовать use case для описания взаимодействий не только пользователь-система, но и для описания интеграций. Также используют диаграмму потоков данных и компонентные схемы.
Например, вы хотите посмотреть варианты пиццы и указываете точку /pizza. API принесёт информацию о цене, акциях и составе продукта. Но вы просили информацию о видах пиццы. Придётся постоянно прописывать конкретные адреса, а это энергозатратно для разработчиков и проблематично для пользователей.
То есть возникают проблемы с выборкой: она либо избыточна, либо недостаточна. REST не может предоставлять точные данные по запросу клиентов, потому что использует один endpoint для одного адреса.
Архитектурный стиль GraphQL позволяет сделать запросы за один раз. Клиент передаёт названия трёх мест, запрашивает нужные данные и ждёт. GraphQL выполнит все запросы и принесёт данные из разных адресов.
GraphQL: стандарт и его особенности
GraphQL — язык запросов для управления данными графов. Он использует разные виды протоколов для передачи информации. GraphQL в основном возвращает ответы в JSON.
Главное отличие GraphQL от REST API в том, что все данные клиент может выбрать всего одним запросом, даже если они будут располагаться в разных источниках. А в REST API придётся сделать выборку и извлекать их уже оттуда.
Разработчики считают GraphQL умным агрегатором, который играет роль оркестратора. Он переадресовывает фрагменты запроса на разные эндпоинты. GraphQL умеет отправлять данные поверх HTTP-протокола, Websocket и SSH. Это удобно, когда вы разрабатываете многофункциональное приложение.
GraphQL имеет три главных блока:
— Queries — запросы
— Schema — схема. Описание типов объектов и полей, принадлежащих каждому объекту
— Resolvers — функция, отвечающая за заполнение информацией полей в схеме. Способ выполнения процедуры определяет разработчик. Например, резолвер может извлекать данные из сервера или стороннего API
Для работы с графовым языком запросов есть утилита GraphiQL. Разработчик интегрирует её с Endpoint GraphQL. Он отправляет запрос серверу на предоставление своей схемы — вы получаете интерфейс для проведения тестов и изучения запросов.
Если с формированием запросов всё понятно, давайте посмотрим основные блоки кода для схем:
— Character — вид среды GraphQL
— Fields (например, name и address) — поля, заполняемые в виде объекта Character. Их находят в ответе на запрос. Каждое поле возвращает то значение, которое обрабатывает
Разберём поля подробно, потому что они составляют значительную часть возвращаемой информации. Итак, они могут быть скалярного вида, объектом, типом ввода, перечисления, объединения и интерфейсом.
Например, скалярные виды — это:
— String — определённые символы в коде UTF-8
— Int — 32-битное целое число
— Float — цифра с плавающим разделительным знаком
— Boolean — логическая информация: true или false
— ID — уникальный идентификатор. Нужен для повторной выборки объекта
GraphQL умеет анализировать синтаксис и проверять формы собственной схемой. Этот API может показаться сложным на стадии создания приложения, но подобное разделение на отдельные элементы — интересная возможность для анализа синтаксиса — позволяет получать чёткие ответы на запросы без дополнительных выборок, в отличие от REST API.
Итак, REST API применяют, если:
— работают с небольшими программами, где нужно обрабатывать простые данные
— пользователи работают с ними одинаково
— нет требований к сложным запросам
GraphQL выбирают, когда:
— у серверного оборудования маленькая пропускная способность. Необходимо снизить количество ввода-вывода данных
— в одном адресе нужно объединить множество источников
— запросы пользователей различны, необходимо прорабатывать разные ответы
Что даёт интеграция по API
1. Мотивирование пользователя совершать действия в продукте
API позволяет связать основной продукт (например, приложение доставки) и игру: за каждую транзакцию пользователь может получать игровую валюту и другие бенефиты. Например, в «Клюкере» от Яндекса — зёрна за прослушивание подкастов.
2. Быстрая авторизация
При использовании классической авторизации по СМС или email около 20-40% пользователей отваливаются ещё на этом этапе: не приходит код, долго ждать, другие барьеры. Если игра интегрирована прямо внутрь приложения через WebView и авторизация происходит через API, то вход будет быстрым и безболезненным.
3. Использование баллов лояльности
Мы можем предложить игроку обменивать заработанные баллы лояльности на какие-то игровые штуки: предметы, покупку суперсилы, уровней и т. д. В обычной схеме такие баллы — это, по сути, скидка, которую бренд делает клиенту за лояльность. Если игрок потратит их в игре, купить товар/услугу за полную стоимость — доходность с такого клиента вырастет. Соответственно, это позволит улучшить экономику бренда.
Как интеграция выглядит на практике изнутри
API-интеграция в игровых проектах может работать по двум сценариям, разберём их на примере Новогоднего адвент календаря, который мы делали для Самоката в прошлом году.
У нас была задача увеличить продажи ряда брендов в категории «Кондитерские изделия». Механика проекта была следующая. Для участия в розыгрыше призов пользователь должен был сделать покупку на сумму от 400 руб в специальной подборке. После покупки он получал индивидуальный код для авторизации в проекте. За каждую единицу товара пользователь получал билетики для розыгрыша.
Как выглядел процесс взаимодействия по авторизации в упрощённом виде:
— Создание базы уникальных кодов авторизации и передача ее нам
— Покупка в приложении Самоката на сумму от 400р
— Отправка SMS с кодом XXXXX авторизации и привязка кода к номеру телефона клиента
— Ввод кода пользователем на сайте
— Проверка наличия код в базе на нашей стороне. Код есть = авторизация
Из прикольного: авторизация в спецпроекте происходила не по номеру или другим личным данным пользователя, а по специально сгенерированному для него коду. По сути, он выступал как ID юзера в базе. Это хорошее решение для обеспечения безопасности данных, особенно если юзеры потенциально могут бояться предоставлять свою персональную информацию на стороннем сайте.
Как выглядел процесс взаимодействия по начислению билетиков розыгрыша:
— Совершение покупки в подборке
— Отправка сообщения, что пользователь с кодом XXXXX сделал покупку N товаров
— Начисление билетиков в базе данных проекта
— Отображение в интерфейсе сайта
Это может работать и в обратную сторону, когда информация о внутриигровых действиях передаётся на сторону основного продукта бренда. Например, юзер может получить баллы лояльности в игре за выполнение заданий, и ему начислят их в магазине/экосистеме бренда.
Звучит просто? Да. Почему это делают не так часто? Сложно :) Сложно с точки зрения ограниченности ресурсов компании. Чтобы написать API для спеца, нужно не так много времени: 1-2 недели или 40-80 человекочасов. Но команда разработки бренда чаще всего занята на год-два вперёд на основных задачах и выдёргивать сотрудников с них не вариант.
Но давайте честно: если вы решаете делать действительно хороший спецпроект, с которого хотите получить деньги, а не похоронить уже имеющиеся, то стоит подумать над выделением ресурсов.
И в случае с API это точно стоит сделать. Например, пользователи нашего новогоднего адвента Самоката за месяц совершили 312К покупок, а самый активный участник собрал 171 билетик розыгрыша, то есть купил 171 товар. Общий рост продаж брендов участников составил +80%.
Кроме того, клиентская команда должна быть подкована в разработке API для внешних проектов, чтобы избежать проблем при релизе. Например, в одном из наших недавних спецов данные о покупках со стороны продукта задублировались при передаче в игру. Это произошло из-за пробелов в коде интеграции от заказчика. Короче, произошёл самоDDoS :) Зато теперь мы знаем, как помочь нашим клиентам предотвратить такие неприятные случаи.
Для кого API будет особенно кстати
Такая фича очень пригодится ритейлерам и другим компаниям, которые продают чужие товары у себя на площадке. В рамках игры они могут предлагать брендам делать задания, связанные с покупкой их товаров или другими действиями вроде подписки на новинки. Из таких компаний кроме Самоката API пользуются, например, Т-Банк, Яндекс.
Кстати, для селлеров маркетплейсов это тоже хорошая и вполне реальная идея. Спецпроекты с API в контексте МП — это отдельная возможность предложить продавцам больше заработать или дать новый рекламный инструмент в рамках площадки. Например, в преддверии Нового года тот же Озон мог бы выпустить адвент со скидками на товары конкретных брендов или подборки по категориям.
Круто! Что дальше?
Если вдруг ещё не пробовали использовать API в своих спецпроектах — самое время начать. Да, в моменте инвестиция может быть дороговатой, но наградой за это будет рост продаж, улучшение пользовательского опыта и увеличение общей лояльности к вашему бренду.