Альтернатива Bitly API для розробників: на що звертати увагу

Якщо ви підшукуєте альтернативу Bitly API, ви, ймовірно, вже вперлися в одну з двох стін: ліміти запитів, які обмежують вашу автоматизацію на доступному за ціною плані, або потрібну функцію, заховану за рівнем, який ви не хочете купувати. Це посібник для розробників про те, що насправді важливо в shortener API - ліміти, ідемпотентність, webhooks, SDK - і як на практиці відбувається перехід.

Це стаття в кластері інженерії. Про форму запиту та основи авторизації, спільні для всіх цих сервісів, читайте в посібнику з безкоштовного URL shortener API - базовому матеріалі, на якому ґрунтується ця стаття.

Де відчутно кусає Bitly API

API Bitly доволі потужний, і для невеликих обсягів він цілком підходить. Тертя з'являється при масштабуванні. Ліміти запитів варіюються від приблизно 1 000 запитів на місяць на найнижчих рівнях до 150 000+ на вищих, плюс додаткові обмеження за хвилину та за годину, задокументовані в довіднику Bitly API. На дешевшому плані саме ці обмеження й гальмують автоматизовані завдання, для яких API, власне, і існує.

Друга стіна - це обмеження за рівнями. Структура груп та організацій, деякі ендпоінти аналітики й більші обсяги запитів доступні лише на вищих рівнях, тож версія API, на яку вистачає бюджету, часто не та версія, під яку писалася ваша інтеграція. Жодне з цього не є справжнім недоліком - так побудоване ціноутворення, - але саме тому команди й починають шукати альтернативи. Власний розбір Bitly API від Rebrandly доходить того самого висновку щодо того, де саме тиснуть ліміти.

Що має давати shortener API, орієнтований на розробників

Якщо відкинути брендинг, хороший shortener API зводиться до чотирьох речей.

1. Ліміти запитів, під які можна планувати. Задокументовані обмеження на вікно часу, прив'язані до робочого простору, не настільки жорсткі на початкових рівнях, щоб їх порушувало пакетне завдання. Передбачуваність важливіша за високий, але непрозорий ліміт.
2. Ключі ідемпотентності (Idempotency-Key). Надсилайте стабільний ключ на кожен логічний запит, і повторна спроба після таймауту поверне оригінальне посилання, а не створить дублікат. Без цього кожна повторна спроба - це ризик.
3. Webhooks. Надсилання подій кліків на ваш ендпоінт замість того, щоб змушувати вас опитувати API аналітики за таймером.
4. Справжні SDK. Офіційні бібліотеки мовами, якими ви користуєтеся, щоб не писати авторизацію та пагінацію вручну.

У детальному розборі лімітів запитів та ідемпотентності пояснено, чому другий пункт важливіший за сам ліміт запитів: безпечний до повторів API на 10 000 запитів кращий за крихкий на 100 000.

Міграція менша, ніж здається (за одним винятком)

Виклик API майже не змінюється. Виклик створення посилання в Bitly та у більшості альтернатив має ту саму форму: авторизація через Bearer-токен, POST з довгим URL, отримання короткого посилання з JSON. Заміна провайдера - це переважно новий base URL, новий токен і відповідність назв полів.

# Bitly
curl -X POST https://api-ssl.bitly.com/v4/shorten \
  -H "Authorization: Bearer $BITLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"long_url": "https://example.com/page"}'

# Elido - same shape, plus an idempotency key
curl -X POST https://api.elido.app/v1/links \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Idempotency-Key: 5f3e-once" \
  -H "Content-Type: application/json" \
  -d '{"destination_url": "https://example.com/page"}'

Якщо викликаєте це з коду, посібник з Python показує патерни повторних спроб та ідемпотентності, які варто застосувати навколо будь-якого з цих викликів.

Частина, яка не маленька: ваші наявні посилання. Коротке посилання продовжує працювати, лише якщо ви контролюєте домен, на якому воно розміщене. Посилання на bit.ly перенести не можна - цей домен належить Bitly. Лише брендовані посилання на вашому власному домені можна перенаправити до нового провайдера без поломок. Тож питання міграції насправді таке: «скільки моїх активних посилань розміщено на домені, яким я володію?» - і відповідь визначає, наскільки чистим буде перехід. План міграції з Bitly детально описує кроки з доменом і редиректами.

Як обрати

Чесний короткий список для API розробника - це Short.io, Rebrandly, Dub та Elido: кожен надає справжній API з SDK. Short.io та Dub орієнтуються на розробників за ціною; Rebrandly - на автоматизацію брендованих доменів. Elido відрізняється поєднанням, на якому інші не фокусуються: ідемпотентність і webhooks за замовчуванням, плюс резидентність даних у ЄС, тож дані про кліки залишаються в регіоні ЄС, а не передаються назовні. Якщо у вашого стека є не лише технічна, а й комплаєнс-вимога, саме це поєднання - привід придивитися до Elido, і ви можете почати розробку проти API на безкоштовному плані, щоб перевірити відповідність перед тим, як зобов'язуватися.

Що б ви не обрали, оцінюйте за лімітами й ідемпотентністю, а не за маркетингом. Саме ці дві речі вирішують, чи буде ваша інтеграція нудною й надійною, чи джерелом дзвінків о другій ночі.

Читайте серію ключових статей

Це стаття в кластері інженерія. Почніть із посібника з безкоштовного URL shortener API, а потім переходьте до детального розбору лімітів запитів та ідемпотентності. Актуальний довідник - це документація API.

Інші статті блогу

• Безкоштовний URL shortener API: форма запиту, авторизація та ліміти
• Ліміти запитів URL shortener API та ідемпотентність
• Як скоротити URL на Python
• Посібник з альтернатив Bitly за прогалинами у функціях
• Міграція з Bitly: покроковий план