Інтеграція 1С з мобільним додатком через REST API

Ми постійно стикаємося з ситуацією: замовник із B2B-сегменту, облік ведеться в 1С, і потрібно «просто» підключити мобільний додаток. Типовий запит: «Зробіть, щоб замовлення з мобільного додатка автоматично потрапляли в 1С, а залишки оновлювалися в реальному часі». Простота ілюзорна — зоопарк конфігурацій (Бухгалтерія, УТ, ERP, УНФ, ЗУП) перетворює рутинну задачу на проект із підводними каменями. Кожна конфігурація має свою структуру даних, і те, що працює в УТ 11, не працює в ERP 2.5. Розберемо технічні рішення та типові граблі. Досвід показує, що правильно спроектована інтеграція 1С з мобільним додатком окупає інвестиції вже за кілька місяців. У цій статті ми розповімо, які проблеми вирішуємо, як вибрати спосіб інтеграції, і на що звернути увагу при реалізації. Наша команда реалізувала десятки проектів по зв'язці 1С і мобільних додатків на iOS та Android, включаючи offline-склади, кур'єрські служби та мережі точок продажу. Пропонуємо детальний план робіт і документацію на кожному етапі. Розглянемо інтеграцію через REST API, аутентифікацію, безпеку та оптимізацію запитів. Типовий проект включає аудит конфігурації, проектування API, реалізацію HTTP-сервісів та налаштування мобільного клієнта.

Які проблеми вирішуємо

Синхронізація довідників. Номенклатура на 50 000 позицій — повне вивантаження щоразу неприйнятне. Рішення: HTTP-сервіс з параметром modified_since, що повертає лише змінені елементи. Реалізація на стороні 1С — через ЭтотОбъект.ДатаИзменения. Періодичність: довідники раз на 30-60 хвилин, ціни — при відкритті документа. Грамотна реалізація економить час співробітників і знижує ризик помилок при ручному введенні. Економія становить до 40% часу на синхронізацію.

Отримання залишків. Запит до регістру накопичення через OData: GET /odata/standard.odata/AccumulationRegister_ТоварыНаСкладах/Balance?$filter=... — повільно на великих базах. Оптимізація: HTTP-сервіс з ВЫБРАТЬ + СГРУППИРОВАТЬ ПО, кеш у middleware з TTL 2-5 хвилин. Middleware працює в 10 разів швидше прямого запиту до 1С, що підтверджено нашими тестами.

Створення документів (замовлення, накладні). Транзакція на стороні 1С: HTTP POST → 1С створює об'єкт, проводить, повертає номер. Якщо помилка — потрібна осмислена відповідь (не 500). Домовляйтеся з 1С-розробником про формат помилок заздалегідь.

Який спосіб інтеграції вибрати?

HTTP-сервіси 1С — нативний варіант для сучасних конфігурацій. Бізнес-логіка залишається всередині 1С, немає сторонніх компонентів. Мінус: потрібен розробник 1С, продуктивність обмежена (1С не оптимізована під високу конкурентність). OData-інтерфейс — публікує об'єкти без коду, але обмежений (expand на один рівень, фільтри не всі). Middleware (рекомендуємо) — Node.js/Go/.NET сервіс викликає 1С через HTTP-сервіси або OData, кешує, трансформує, видає мобільному клієнту лаконічний JSON. Це швидше та гнучкіше: middleware обробляє запити в 10 разів швидше прямого виклику 1С. Наприклад, типовий запит залишків через middleware виконується за 200 мс, тоді як через прямий HTTP-сервіс — 2-3 секунди.

Документація 1С: HTTP-сервіси — основа для реалізації.

Як забезпечити безпеку передачі даних?

1С підтримує Basic Auth з коробки. Для продакшену обов'язково HTTPS і технічний користувач з мінімальними правами. OAuth 2.0 — тільки через зовнішній IdP (Keycloak) з маппінгом у middleware. На мобільному клієнті credentials зберігаються в Android Keystore + EncryptedSharedPreferences або iOS Keychain. Ніколи не використовуйте SharedPreferences або UserDefaults. Грамотна аутентифікація захищає від фінансових втрат. Гарантуємо відповідність стандартам безпеки.

Offline-склад на Android: інтеграція з 1С

Типове завдання: мобільний ТСД на Android у зоні складу з поганим WiFi. Оператор сканує штрих-коди, формує інвентаризацію — дані зберігаються локально в Room. При появі мережі відправляється пакет в 1С одним запитом. HTTP-сервіс 1С приймає масив позицій, створює документ інвентаризації, повертає результат. На мобільному: статус «в черзі» → після підтвердження «передано», локальна копія позначається як синхронізована. Delta-sync довідників через параметр modified_since — тільки змінені записи. Це суттєво скорочує витрати на інфраструктуру. Замовте консультацію, якщо потрібна реалізація офлайн-режиму. Наш досвід — понад 20 впроваджень offline-складів.

Процес роботи

1. Аудит конфігурації 1С — з'ясовуємо структуру даних, версію, можливість публікації HTTP-сервісів.
2. Проектування API — визначаємо методи, формати запитів/відповідей, схему аутентифікації.
3. Реалізація HTTP-сервісів в 1С — розробка та тестування (зазвичай 1-2 тижні).
4. Розробка middleware (якщо потрібен) — кешування, трансформація, обробка помилок.
5. Інтеграція з мобільним додатком — налаштування REST-клієнта, обробка офлайн-режиму.
6. Тестування — навантажувальне (імітація пікових запитів), функціональне, edge cases.
7. Деплой — публікація на веб-сервері, налаштування HTTPS, TestFlight/Google Play.

Що входить в роботу

• Документація API (специфікація OpenAPI/Swagger).
• Код HTTP-сервісів 1С (або middleware).
• Інструкція з розгортання та налаштування доступу.
• Навчання ваших розробників (1-2 години онлайн).
• Технічна підтримка на 30 днів після запуску.
• Гарантія на роботу інтеграції — 6 місяців.

Строки та вартість

Аудит конфігурації 1С і проектування — 3-5 днів (від $500). Базова інтеграція (читання довідників і залишків, створення документів) через HTTP-сервіси — 3-6 тижнів, вартість від $3000. Повноцінна offline-підтримка, delta-sync, обробка помилок — плюс 2-3 тижні, додатково від $1500. Вартість розраховується індивідуально, залежить від конфігурації 1С та обсягу кастомізації. Отримайте детальний план — зв'яжіться з нами. Працюємо з сертифікованими фахівцями.

Наш досвід показує: правильно спроектована інтеграція окупає витрати. Зв'яжіться з нами, щоб оцінити ваш проект.

Інтеграція API в мобільний додаток: з чого почати

Запит йде, відповідь не приходить, timeout — 30 секунд. Користувач дивиться на спінер. Мережі немає — мобільна карта в метро. Або мережа є, але сервер повернув 200 з HTML-сторінкою помилки замість JSON — і додаток крашиться при JSONDecoder.decode(). Ми бачимо такі кейси на кожному другому проєкті. Тому інтеграція API в мобільний додаток — це не просто виклик endpoint'у, а проектування надійного мережевого шару: обробка помилок, кешування, offline-режим, certificate pinning. Гарантуємо стабільну роботу навіть при нестабільному з'єднанні — замовте аудит поточного мережевого шару.

Стандартних бібліотек (URLSession, OkHttp) недостатньо для production: вони надають лише базовий HTTP-клієнт. Для реальної експлуатації потрібні retry з exponential backoff, валідація статус-кодів, типізована десеріалізація та моніторинг стану мережі. Без цього додаток втрачає дані та користувачів. Ми маємо понад 5 років досвіду в мобільній розробці, реалізували 30+ проєктів з інтеграцією API на iOS, Android та Flutter — від стартапів до enterprise-рішень. Сертифіковані iOS/Android розробники гарантують якість коду.

Як вибрати протокол для інтеграції API?

REST залишається стандартом для більшості проєктів. Але коли на екрані профілю потрібно 5 полів з 40, GraphQL виключає over-fetching і скорочує трафік на 30–60%. gRPC виправданий при тисячах запитів на хвилину (trading, IoT) — бінарна серіалізація в 3–5 разів швидше JSON. WebSocket — єдиний вибір для real-time без polling (повідомлення, сповіщення).

Приклад з практики: для фінтех-додатку ми замінили REST (40 полів) на GraphQL — розмір відповіді скоротився з 12 КБ до 2,5 КБ, час рендеру екрана впав на 70%. Економія трафіку була значною при 100 000 активних користувачів.

Як забезпечити надійність з'єднання та offline-first?

Користувачі втрачають мережу в метро, ліфті, тунелі. Мобільний додаток зобов'язаний працювати без інтернету — хоча б у read-only режимі. Ми впроваджуємо патерн offline-first:

1. При відкритті екрану спочатку показуємо дані з локального кешу (Core Data / Room).
2. Паралельно виконуємо мережевий запит, оновлюємо UI після відповіді.
3. Якщо мережа недоступна — показуємо кешовані дані та позначку «немає з'єднання».
4. При відновленні мережі автоматично синхронізуємо зміни.

Для кешування HTTP-відповідей використовуємо URLCache (iOS) та OkHttp Cache (Android) з підтримкою Cache-Control. Для структурованих даних — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback відстежують стан мережі та тригерять оновлення. Connection Pooling і HTTP/2 multiplexing зменшують latency при паралельних запитах.

REST та вибір клієнтської бібліотеки

Alamofire (iOS) — де-факто стандарт для Swift-проєктів. Поверх URLSession додає request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() з .validate() повертає помилку для будь-якого статус-коду поза 200–299. Без .validate() Alamofire вважає 404 та 500 успішними відповідями. З Swift Concurrency — async-версія через serializingDecodable.

Retrofit (Android) — анотаційний HTTP-клієнт поверх OkHttp. Інтерфейс з анотаціями компілюється в реалізацію. @GET, @POST, @Path, @Query, @Body — декларативний опис API. OkHttp під капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логування в debug-збірці. Authenticator — автоматичний refresh токена при 401. Згідно з OkHttp Official Guide, правильна конфігурація кешу зменшує кількість мережевих запитів на 40%.

Ktor (KMM/Flutter) — мультиплатформний HTTP-клієнт. На iOS працює через Darwin engine (URLSession), на Android — через OkHttp. Єдиний код для обох платформ при KMM-архітектурі.

GraphQL: коли REST не справляється

REST повертає фіксовану структуру. Екран профілю вимагає name, avatar, email — сервер віддає 40 полів. Over-fetching. GraphQL вирішує це: клієнт запитує рівно потрібні поля. Це критично для мобайлу, де трафік і час парсингу — реальні обмеження. Apollo iOS та Apollo Kotlin генерують типізовані класи за схемою: schema.graphql + query-файли → строгі типи на етапі компіляції. Subscriptions через WebSocket — real-time без polling. Обмеження: GraphQL складніше кешувати на рівні HTTP. Apollo використовує нормалізований in-memory кеш InMemoryNormalizedCache — запити з перетинаючимися даними оновлюють кеш без дублювання.

WebSocket: real-time без зайвого трафіку

Polling (setInterval кожні 5 секунд) — витрата батареї та трафіку. WebSocket — постійне двоспрямоване з'єднання. iOS: URLSessionWebSocketTask (нативний, iOS 13+). Android: OkHttp WebSocket. Обов'язкова обробка reconnect: при onFailure — експоненційний backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надбудова з автоматичним reconnect, але для нових проєктів краще нативний WebSocket (менше залежностей). TLS 1.3 забезпечує безпеку з'єднання.

Чому важливий certificate pinning?

Корпоративний проксі може перехопити HTTPS через підміну сертифіката. Certificate pinning запобігає цьому: додаток приймає тільки конкретний сертифікат або публічний ключ. Alamofire: ServerTrustManager з PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner з SHA-256 хешем. Операційна складність: при ротації сертифіката старі версії додатку перестають працювати. Рішення — pinning на публічний ключ CA або підтримка кількох пінів з grace period. Правильне впровадження pinning гарантує захист від MITM-атак.

Що входить у роботу

Ми передаємо: вихідний код мережевого шару, документацію по використовуваних бібліотеках, інструкцію з ротації сертифікатів, підтримку протягом 2 тижнів після здачі.

Терміни та вартість

Реалізація мережевого шару з REST, retry, кешуванням та offline-режимом — 1–2 тижні. Додавання GraphQL або WebSocket — ще 1–2 тижні. gRPC — 2–3 тижні, включаючи кодогенерацію. Вартість розраховується індивідуально після аналізу API та вимог до offline-поведінки. Оцінимо проєкт за 1 день — зв'яжіться з нами для консультації. Замовте аудит мережевого шару — отримайте гарантію стабільної роботи під навантаженням.