Что такое API-интеграция: польза и риски для бизнеса

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

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

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

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

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

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

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

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

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

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

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

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

Если какая-то информация переносится всего несколько раз в месяц, сделать это вручную часто и дешевле, и надежнее. Если разработка и сопровождение интеграции стоят больше, чем сэкономленное ею время, такое вложение не оправдано.

Если задачу уже решает готовый плагин или встроенное подключение, индивидуальная разработка не требуется. Для распространенных потребностей, таких как оплата и доставка, большинство платформ предлагает готовые подключения, а индивидуальная разработка имеет смысл лишь там, где есть бизнес-правило, которое готовое решение не покрывает. Вопрос, который стоит задать себе, звучит так: действительно ли потребность особенная.