Backend API Communication
Тут ми розглянемо з теоретичної сторони, як комунікувати з бекендом у апплікейшенах.
Чому одночасно Webitel SDK та Raw Endpoints?
Так склалось історично, але, сподіваюсь, колись це пройде і будуть тільки Webitel SDK ендпоінти.
Webitel SDK Endpoints
Webitel SDK ендпоінти - це ендпоінти, згенеровані автоматично через Open API (aka Swagger).
Відповідно, замість того щоб самостійно будувати url, і все таке - ми просто передаємо параметри у методи, які нам дає бібліотека, згідно певної сутності. Список цих сутностей та ендпоінтів можна подивитись на webitel swagger'i.
З запитами, які мутують дані, все просто: body виглядає стандартно. А от з search ендпоінтами складнощі, бо генерування api налаштоване так, що параметри необхідно передавати по порядку, а не одним обʼєктом.
Тобто, замість
service.searchSmth({ page, size, search });нам треба робити ось так
service.searchSmth(page, size, search);а отже, відповідно, порядок параметрів має значення.
Також у service з api методами, які ми створюємо, можна (і потрібно!) передати наш axios instance, отже, всі інтерцептори і хедери, застосовувані в ньому, будуть застосовані також.
Raw Endpoints
Тут все доволі безхитрісно і типово: ми маємо axios instance, ми маємо baseUrl групи ендпоінтів по певній сутності, і, ми просто формуємо url запиту, його body - та й все.
Проблема в тому, що ці ендпоінти не описані у сваггері, а отже, інформація про них передається традиційно: із уст в уста. 🫠
Тонкощі роботи з ендпоінтами
Falsy values
API Gateway на бекенді налаштований так, що не вертає полів, які мають falsy значення.
А нам-то ці поля потрібні!
Отже, ми маємо в ці поля сетати дефолтні для них значення.
WebSocket
Для організації роботи з дзвінками або чатами використовується WebSocket зʼєднання.
Як правило, на Webitel SDK WebSocket'i (вебсокет обгорнутий у бібліотеку, яка має методи керування ним) працює Workspace та Supervisor. А Omni-widget - на raw WebSocket'i (створюємо і відкриваємо коннекшен самостійно).
А як додать апішку-то?
А це описано ось тут