API простыми словами: зачем оно сайту и приложению

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

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

1. Что происходит между экраном и данными

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

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

API можно сравнить с меню разрешённых действий, но не с открытой дверью во все данные компании. Например, покупателю разрешено видеть собственные заказы, а сотруднику склада — заказы на сборку. Эти границы нужно спроектировать и проверить, они не возникают из самого слова API.

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

2. Зачем сайту и приложению общий источник данных

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

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

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

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

3. Какие вопросы задать до разработки

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

Затем уточните границы:

• Какие функции уже доступны, а какие предстоит разработать?
• Где находятся основные данные и кто вправе их менять?
• Как пользователь подтверждает доступ к своему аккаунту?
• Что произойдёт при отсутствии интернета или медленном ответе?
• Как обрабатывается повторная попытка одного действия?
• Кто поддерживает обмен после изменения внешнего сервиса?

Особенно важны действия с последствиями: создание заказа, запись на время, изменение контактов. Повтор запроса после обрыва связи не должен незаметно создавать второй заказ. Способ защиты от повторов определяется при проектировании, а затем проверяется на тестах.

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

4. Что должно войти в приёмку

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

Проверьте взаимодействие двух интерфейсов: заказ, созданный на сайте, должен отображаться в приложении по согласованным правилам. Уточните, как быстро видны изменения и какое сообщение появляется, если данные ещё не обновились. Такие детали формируют реальный опыт клиента.

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

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

Источники

• MDN: определение API.
• MDN: обзор HTTP и обмен запросами и ответами.