Разработка API для мобильного приложения на базе 1С-Битрикс

Создание API для мобильного приложения на Битрикс

Стандартный REST-модуль Битрикс (rest) заточен под вебхуки CRM и Битрикс24 — он не годится для публичного мобильного API с каталогом, корзиной и заказами. Сессионная авторизация через cookie в нативном приложении не работает без WebView, а встроенные эндпоинты не покрывают e-commerce сценарии. Документация 1С-Битрикс рекомендует для мобильных приложений разрабатывать кастомные контроллеры поверх ядра. Мы — команда сертифицированных битрикс-разработчиков с 10+ годами в продакшене. Разработали API для 15+ мобильных приложений, включая дилерские сети и интернет-магазины.

Почему сессионная авторизация не подходит?

Стандартная сессия Битрикс привязана к cookie и не работает в мобильном приложении без WebView. JWT-токены лишены этого недостатка: они передаются в заголовке Authorization: Bearer ..., не требуют хранения на сервере и легко обновляются через refresh-токены. JWT-авторизация в 2 раза быстрее сессионной при проверке токена — сервер не обращается к хранилищу сессий для каждого запроса. Наши инженеры реализуют этот механизм с нуля.

GET    /api/v1/catalog/sections         — список разделов
GET    /api/v1/catalog/products         — товары с фильтром и пагинацией
GET    /api/v1/catalog/products/{id}    — карточка товара
POST   /api/v1/cart/add                 — добавить в корзину
GET    /api/v1/cart                     — состояние корзины
POST   /api/v1/order/create             — оформить заказ
POST   /api/v1/auth/login               — авторизация
POST   /api/v1/auth/refresh             — обновление токена

Архитектура API

Оптимальная точка входа — единый файл /api/v1/index.php, который маршрутизирует запросы через роутер. Используем компонент маршрутизации Битрикс или реализуем минимальный роутер самостоятельно. Формат ответа — единообразный JSON-конверт с полями success, data/error и meta.

Авторизация через JWT

Реализуем JWT-авторизацию с контроллером:

class AuthController extends \Bitrix\Main\Engine\Controller
{
    public function loginAction(string $login, string $password): array
    {
        $result = \CUser::Login($login, $password, 'Y');
        if ($result !== true) {
            return ['error' => 'Invalid credentials'];
        }

        $userId = \CUser::GetID();
        $payload = [
            'sub' => $userId,
            'iat' => time(),
            'exp' => time() + 3600 * 24 * 30,
        ];
        $token = JwtHelper::encode($payload, JWT_SECRET);
        $refresh = JwtHelper::generateRefresh($userId);

        return ['access_token' => $token, 'refresh_token' => $refresh];
    }
}

Refresh-токены хранятся в таблице bl_api_tokens с полями user_id, token_hash, expires_at, device_id. В middleware каждого запроса декодируем JWT, получаем user_id и авторизуем пользователя через \CUser::SetOnStartSession() только для текущего запроса.

Каталог и товары

Контроллер каталога с поддержкой фильтра и пагинации:

public function getProductsAction(int $sectionId = 0, int $page = 1, int $limit = 20, array $filter = []): array
{
    $offset = ($page - 1) * $limit;

    $bitrixFilter = [
        'IBLOCK_ID' => CATALOG_IBLOCK_ID,
        'ACTIVE' => 'Y',
        'ACTIVE_DATE' => 'Y',
    ];
    if ($sectionId > 0) {
        $bitrixFilter['SECTION_ID'] = $sectionId;
        $bitrixFilter['INCLUDE_SUBSECTIONS'] = 'Y';
    }
    // применяем пользовательские фильтры

    $items = \Bitrix\Iblock\Elements\ElementCatalogTable::getList([
        'filter' => $bitrixFilter,
        'limit' => $limit,
        'offset' => $offset,
        'select' => ['ID', 'NAME', 'DETAIL_PICTURE', 'PREVIEW_TEXT'],
    ]);

    return ['items' => $this->formatProducts($items), 'page' => $page, 'limit' => $limit];
}

Цены получаем через \Bitrix\Catalog\PriceTable::getList() с учётом группы пользователя. Для ускорения запросов используем индексы на b_catalog_price и b_catalog_product. Кеширование ответов каталога — ключевой элемент производительности.

Как реализовать кеширование для каталога? (шаги)

1. Подключите \Bitrix\Main\Data\Cache в контроллере.
2. Установите время жизни кеша (TTL) — 300 секунд для каталога.
3. Используйте тегированное кеширование с тегами инфоблоков (iblock_id_XX) для автоматической инвалидации при изменении товаров.
4. Для динамических запросов (корзина, заказы) используйте Redis как внешнее хранилище.

Redis снижает время ответа в 4–6 раз по сравнению с файловым кешем. Выбор зависит от бюджета проекта.

Корзина и заказы

Корзина хранится в стандартной b_sale_basket через \Bitrix\Sale\Basket. Для неавторизованного пользователя корзина привязывается к FUSER_ID, передаваемому в заголовке X-Fuser-Id. При авторизации корзина мигрирует к USER_ID. Оформление заказа — \Bitrix\Sale\Order::create() с передачей адреса доставки, способа оплаты и доставки. API возвращает order_id и ссылку на оплату.

Формат ответа и ошибки

Единообразный JSON-конверт:

{
  "success": true,
  "data": { ... },
  "meta": { "page": 1, "total": 142 }
}

При ошибке:

{
  "success": false,
  "error": { "code": "PRODUCT_NOT_FOUND", "message": "Товар не найден" }
}

HTTP-статусы: 200 OK, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error.

Кейс: мобильное приложение для дилерской сети (из нашей практики)

Задача: iOS/Android-приложение для 200 дилеров — просмотр каталога, проверка остатков, оформление заказа.

Особенности:

• Индивидуальные цены по группам покупателей (b_catalog_price, группа из b_user)
• Остатки из b_catalog_store_product — несколько складов, нужен агрегированный остаток
• Push-уведомления через FCM при смене статуса заказа
• Кеширование ответов каталога на 5 минут через Bitrix Cache (\Bitrix\Main\Data\Cache)

Результат: 200 активных пользователей, среднее время ответа API 120 мс, нагрузка 50 RPS в пике.

Процесс работы

1. Аналитика: разбор бизнес-логики, интеграционных точек, формирование спецификации API.
2. Проектирование: разработка архитектуры, схемы эндпоинтов, выбор протоколов (REST, JSON:API).
3. Реализация: написание контроллеров, авторизации, кеширования, интеграций (доставка, оплата).
4. Тестирование: модульные тесты, нагрузочное тестирование (JMeter), проверка безопасности.
5. Деплой: настройка сервера (Nginx, PHP-FPM), миграции БД, развёртывание на стейджинг и продакшн.

Сроки: от 3 до 10 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита проекта. Получите консультацию по вашему проекту — оценим объём работ и предложим оптимальную архитектуру.

Что входит в разработку?

• Роутер и структура контроллеров /api/v1/
• JWT-авторизация с refresh-токенами и поддержкой нескольких устройств
• Эндпоинты каталога с фильтрацией, пагинацией и ценами по группам
• Корзина и оформление заказа через \Bitrix\Sale
• Стандартизированный формат ответа и коды ошибок
• Кеширование ответов каталога, документация в формате OpenAPI

Свяжитесь с нами для обсуждения деталей. Опыт работы — более 5 лет, 15+ успешных проектов, сертификаты 1С-Битрикс.