Як LMS Collaborator інтегрується з усіма системами, або що таке API та Webhook
Sorry, this entry is only available in UA and EN.
Якщо притримуватися офіційної версії, то application programming interface (API) – це набір визначень підпрограм, протоколів взаємодії та засобів для створення програмного забезпечення. Він слугує таким собі містком, який допомагає розробнику поєднати дві окремі системи і зробити із них один злагоджений механізм.
Звучить дуже цікаво, але людині, яка не має жодного відношення до програмування, геть незрозуміло.
Саме тому ми вирішили поспілкуватися з CTO & Co-Founder LMS Collaborator Олександром Слубським, щоб отримати переклад з технічної мови на людську і з’ясувати нарешті, що ж таке інтерфейс програмування застосунків і навіщо він потрібен.
Про API простими словами
Уявіть, що ви прийшли до McDonald’s за улюбленим “Дабл чізбургер меню”. Співробітники кухні не приймають ваше замовлення напряму, адже вони зайняті смаженням картоплі, збиранням бургерів і приготуванням кави. Якщо вони будуть відволікатися на теревені з кожним новим клієнтом, то вам доведеться простояти в черзі не одну годину.
Саме тому потрібен такий собі посередник, який передасть ваше замовлення на кухню. У нашому випадку цю роль виконує термінал самообслуговування або ж касир. Як підсумок, персонал закладу не відволікається від своєї безпосередньої роботи, а ви отримуєте готове замовлення впродовж кількох хвилин – всі у виграші.
API працює за тим же принципом.
Це той посередник, який дозволяє сервісам взаємодіяти між собою. До прикладу, сама по собі LMS не може надсилати SMS-повідомлення співробітникам і сповіщати їх про призначення нового завдання або тесту, а от мобільні оператори можуть. Тоді API виконує функцію того ж термінала самообслуговування, що допомагає налагодити зв’язок між цими системами.
Колись давно це було чимось новим і незвичним, але зараз вважається загальновизнаним стандартом. Так чи інакше, всі сервіси мають свої API.
Відкрийте будь-який застосунок на телефоні, ту ж “Дію”. По суті, у вашому гаджеті є тільки зручний інтерфейс і мінімум логіки, адже більша частина айсбергу лежить десь на серверах. І от за допомогою API ці дві частини застосунку комунікують між собою.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
До його появи для взаємодії з іншою системою потрібно було отримати доступ до її бази напряму, що небезпечно з погляду збереження конфіденційності даних. Тоді як API дозволяє вам відслідковувати, хто робить цей запит, як часто, чи має він на це дозвіл тощо. Тобто безпека вашого сервісу знаходиться під вашим безпосереднім контролем.
Крім того, всі бази різні. API ж дозволяє вам отримувати дані та взаємодіяти з ними в одному форматі. Більшість так робить, і тому це зручно. І хоча стандарт Open API не є обов’язковим, його все ж прийнято використовувати за замовчуванням.
Інтеграція з LMS Collaborator
Ми отримуємо запити щодо підключення сторонніх сервісів до системи дистанційного навчання ледь не щотижня. Однак, тут може бути два варіанти розвитку подій.
Насамперед все залежить від того, наскільки популярним є подібне звернення. Якщо це вже не перший схожий запит за останні кілька місяців, то ми можемо інтегрувати такий функціонал безпосередньо в саму систему. Якщо ж це щось таке унікальне, що потрібно тільки одному клієнту, тоді він може використати наші API, щоб підключити бажаний сервіс на своїй стороні.
Наведемо приклад із життя. Припустимо, що до нас звернулася компанія, яка навчає персонал і хоче отримувати детальні аналітичні звіти для виявлення проблемних зон. В рамках LMS Collaborator зберігається вся інформація щодо проходження курсів співробітниками – їх прогрес, результати, час та інші метрики. Однак для того, щоб візуалізувати дані, потрібен спеціальний сервіс, той же Power BI.
Виходить, що у нас є дві різні платформи – програмне забезпечення для створення звітів та інформаційних панелей, а також сама система дистанційного навчання.
Приклад інтеграції LMS Collaborator і Power BI.
Візуалізація даних компанії Kernel
Ось тут на сцену й виходить API.
Задача програмістів полягає у тому, щоб “склеїти” ці системи між собою. Тоді керівник компанії зможе зайти безпосередньо до Power BI та ознайомитися з актуальними даними про навчальну активність співробітників, які періодично витягуються з LMS. Для цього йому достатньо обрати потрібний дашборд з такими ключовими метриками, як кількість розпочатих курсів за певний період, прогрес проходження по підрозділах або ж рейтинг найпопулярніших програм.
Так дві різні системи зв’язуються в одну за допомогою API.
Якщо ж ми розуміємо, що цей функціонал потрібен великій кількості користувачів, тоді задача описується, ставиться у roadmap і йде у розробку. Наприклад, клієнт хоче інтеграцію з телеком-провайдером, щоб SMS-повідомлення відправлялися тільки через Lifecell або Kyivstar. Тоді ми звертаємося до цих операторів по API-документацію, налаштовуємо у себе цю інтеграцію, і система надсилає провайдеру запит кожного разу, коли необхідно відправити повідомлення студентам курсу.
Тобто, насамперед, це історія про взаємодію з іншою стороною. Звісно, є сервіси, які просто не мають API. Тоді ми ніяк з ними не інтегруємося. Але це здебільшого виключення з правила, адже 99% сучасних систем працюють саме по АРІ.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
У такий спосіб ми можемо підключити до системи дистанційного навчання необмежену кількість сторонніх сервісів. Та все ж, більшість API має й свої ліміти, зокрема на чисельність запитів. Це зроблено для того, щоб не зламати чужу систему просто бездумно роблячи мільйони звернень на секунду. Тому при інтеграції програміст завжди має враховувати, що іншу сторону не можна викликати частіше за встановлене обмеження.
Крім того, варіант один раз налаштувати API і забути про їх існування також не працює. Зазвичай оновлення інтегрованих сервісів жодним чином не впливає на роботу LMS. Старі API прийнято залишати без змін. Але якщо оновлення суттєві, то ми все ж отримаємо нову адресу.
Попередня зв’язка при цьому продовжує діяти певний період часу, наприклад, півроку, рік, два роки. Нам, як стороні, яка налаштовує взаємодію, має прийти сповіщення про зміни, а також нова документація для перепідключення, тому стежити за цим потрібно на постійній основі.
Також хочу зауважити, що попри досить популярний стереотип, який шириться онлайн-простором, різні API, інтегровані до однієї системи, не можуть конкурувати між собою. Єдине, що вони можуть – якийсь час не працювати через проблеми на іншій стороні, але аж ніяк не через внутрішній конфлікт. Вирішується така ситуація звичайним прозаїчним зверненням до техпідтримки, тож перейматися через це точно не варто.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
Види API
Різні джерела пропонують нам різну категоризацію. Та правда полягає у тому, що загалом API поділяються всього на два види – публічні та приватні. Все інше то вже варіації на тему.
Публічні API відкрито розміщені у мережі. Щоб їх отримати, вам не потрібно авторизуватися та вводити логін чи пароль. Як правило, це якісь загальновідомі дані, щось по типу погоди. Ви просто заходите на потрібний вам сайт і знаходите його API. Після інтеграції з вашим сервісом він також зможе показувати прогноз погоди на кожен день.
За приватними ж API необхідно звертатися напряму до постачальника. Саме він вирішує, надати вам доступ до документації чи ні. До прикладу, API LMS Collaborator є закритими. Отримати до них доступ можна тільки після авторизації.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
Щодо партнерських API, які досить часто виділяють як окремий вид, то, по суті, їх також можна віднести до приватних. Єдина різниця полягає у тому, що вам видається такий собі ідентифікатор партнера. Так зручніше, тому що не потрібно кожен раз вводити свій логін і пароль, достатньо буде вашого унікального ключа. Ось і всі відмінності.
Стосовно того, яким же API варто надати перевагу, то все залежить від поставленої задачі.
Насамперед тут варто зрозуміти одну важливу річ. Публічні API розраховані на читання. Інакше кажучи, ви можете тільки отримувати дані. Наприклад, коли у вас є інтеграція з платіжною системою, то взаємодія йде в обидві сторони. В той же час, використовуючи публічні API, ви не можете взяти і записати в НБУ свій курс валют – тільки прочитати його.
Крім того, вони безкоштовні, а це означає, що ніхто не гарантує вам стабільність їх роботи. Ну не працює щось і не працює, що поробиш.
Також особливої уваги заслуговують спеціальні сервіси, як Zapier, IFTTT та Integrately, на яких можна знайти і поєднати різні API. Це такі собі проміжні інструменти, які, по суті, звертаються до другої сторони замість вас. Вони зручні, але зважайте на те, що безкоштовні варіанти, на відміну від платних, мають досить обмежений функціонал.
Звісно, краще домовлятися з кінцевою стороною напряму, але це більше рівень великих компаній: вони дуже піклуються про безпеку і розглядають такі сервіси як додатковий ризик, тому не хочуть віддавати туди свої дані.
Якщо ж говорити про менші організації, то для них це буденна практика. У такий спосіб вони заощаджують на наймі програмістів. Менеджер пройшов курс з користування подібним сервісом і за день зробив те, що розробник робив би з нуля тиждень, і обійшлося б у копійочку.
Тож все залежить від кінцевої мети, розміру компанії та її внутрішньої політики.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
Потенційні загрози
Попри те, що API вважається більш безпечним форматом, ніж той, що існував кілька десятиліть тому, коли доводилося давати доступ до бази напряму, він теж має свої недоліки.
В теорії, той самий хакер може виманити логін і пароль клієнта, з яким ви інтегрувалися, і так увійти до системи. Щоправда, тут вже мова більше про соціальну інженерію, тобто таке шахрайство, але це досить часто працює. Фактично, через API зловмисник може зробити все те, що і клієнт через браузер, тому це досить серйозна проблема.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
Ну і знову ж таки, обмеження на кількість запитів – це також частина безпеки. Логіка тут проста. Будь-який сервіс може “лягти”, якщо отримуватиме забагато викликів на секунду. API ж, у свою чергу, дозволяє обмежити ту сторону, яка надсилає йому запити, тим самим убезпечуючи роботу всієї системи.
API vs Webhook – у чому різниця?
Досить часто ці два поняття плутають. Воно й не дивно, адже, по суті, це два дзеркальні процеси. І якщо API дозволяє клієнту викликати нашу систему дистанційного навчання, то Webhook – навпаки, дає нам можливість звертатися до нього.
Реалізація Webhook на платформі
Здавалося б, навіщо це потрібно?
Звісно, ви можете, до прикладу, кожну хвилину робити API-запит, щоб дізнатися, чи пройшов хтось зі студентів ваш курс. Так теж буде працювати, але навіщо все ускладнювати? Адже можна викликати LMS тільки тоді, коли хтось пройде певний курс, тобто, налаштувати умову для активації дії. Саме так і працює Webhook.
Щоправда, він також має бути у зв’язці з якимись API, які пишуться на стороні клієнта. Це взаємодія двох систем за принципом машина-машина, у якій люди участі не беруть. Іншими словами, Webhook доповнює API, дозволяючи викликати його тоді, коли клієнту потрібно.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
На практиці це виглядає так.
Нашому клієнту потрібно було, щоб ми викликали його API кожен раз, коли комусь відправляється повідомлення. Він хотів, щоб його співробітники отримували сповіщення щодо навчального процесу не на електронну пошту чи телефон, а через інші внутрішні канали.
У цьому випадку все, що нам необхідно – викликати його сторону, коли надсилається будь-яке повідомлення в рамках LMS, як от про призначення на курс. Для цього і використовується Webhook, який виглядає як звичайна URL-адреса. Ми звертаємося до нього кожного разу, коли спрацьовує тригер, тобто у разі отримання повідомлення одним зі студентів, а далі клієнт вже сам із ним взаємодіє на власний розсуд.
Інакше це ніяк не реалізуєш. Ми не можемо відправляти повідомлення безпосередньо в API, бо не знаємо, куди. А от Webhook якраз дозволяє робити це тоді, коли спрацьовує тригер. Якби у нас не була реалізована ця функція, то нам би довелося десь ці повідомлення збирати і тримати у себе, а клієнт мав би кожні кілька хвилин робити запити і перевіряти, чи не змінився статус з моменту його останнього звернення.
В іншому ж, механіка роботи API та Webhook досить схожі.
Зокрема, це стосується і випадків, коли події на стороні сервера відбуваються занадто часто. Тоді черга і, відповідно, час реакції на повідомлення зростатиме, а запити будуть накопичуватися допоки наш клієнт їх поступово не обробить або ж не зупинить свою роботу через перевантаження. Для цього і існують обмеження на кількість викликів, про які вже згадувалося раніше.
Тобто як ми можемо іншу сторону зламати, якщо відправлятимемо забагато запитів, так і вона може зламати нас.
Олександр Слубський, CTO & Co-Founder LMS Collaborator
