Альтернатива API Bitly для разработчиков: на что обратить внимание

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

Материал входит в кластер engineering. О форме запросов и основах авторизации, общих для всех подобных API, рассказывает руководство по бесплатному API URL-сокращателя - на нём и строится этот материал.

Где именно Bitly подводит

API Bitly функциональный, и для низких объёмов использования он вполне годится. Проблемы проявляются при масштабировании. Ограничения по частоте запросов варьируются примерно от 1000 запросов в месяц на самых низких тарифах до 150 000+ выше, плюс поминутные и почасовые ограничения сверху - это описано в справочнике API Bitly. На более дешёвом тарифе эти ограничения тормозят как раз те автоматизированные задания, ради которых и нужен API.

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

Что должен давать API сокращателя, ориентированного на разработчиков

Уберите брендинг, и хороший API сокращателя сводится к четырём вещам.

1. Ограничения по частоте запросов, на которые можно опираться в планировании. Задокументированные ограничения по временным окнам, привязанные к рабочему пространству, не настолько жёсткие на начальных тарифах, чтобы пакетное задание их превысило. Предсказуемость важнее высокого, но непрозрачного лимита.
2. Ключи идемпотентности. Отправляйте стабильный ключ для каждого логического запроса, и повторная попытка после таймаута возвращает исходную ссылку вместо создания дубликата. Без этого каждая повторная попытка - это риск.
3. Вебхуки. Отправка событий кликов на ваш эндпоинт вместо постоянного опроса API аналитики по таймеру.
4. Настоящие SDK. Официальные библиотеки на языках, которые вы используете, чтобы не писать вручную авторизацию и пагинацию.

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

Миграция проще, чем кажется (кроме одной части)

Сам вызов API меняется незначительно. Вызов создания ссылки у Bitly и большинства альтернатив имеет одинаковую форму: авторизация через bearer-токен, POST с длинным URL, чтение короткой ссылки из JSON. Смена провайдера - это в основном новый базовый 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 отличается сочетанием, на котором остальные не фокусируются: идемпотентность и вебхуки по умолчанию, плюс резидентность данных в ЕС, благодаря чему данные о кликах остаются в регионе ЕС, а не передаются вовне. Если в вашем стеке важна не только техническая линия, но и линия соответствия требованиям, эта комбинация - повод присмотреться к Elido, и вы можете протестировать API на бесплатном тарифе, прежде чем принимать решение.

Что бы вы ни выбрали, оценивайте по ограничениям и идемпотентности, а не по маркетингу. Именно эти два фактора определяют, будет ли ваша интеграция скучной и надёжной или источником звонков в два часа ночи.

Читайте цикл материалов от базовой статьи

Этот материал входит в кластер engineering. Начните с руководства по бесплатному API URL-сокращателя, затем переходите к подробному разбору ограничений по частоте запросов и идемпотентности. Актуальный справочник - документация API.

Читайте также в блоге

• Бесплатный API URL-сокращателя: форма запроса, авторизация и ограничения
• Ограничения по частоте запросов и идемпотентность API URL-сокращателя
• Как сократить URL на Python
• Руководство по альтернативам Bitly с точки зрения пробелов в функциях
• Миграция с Bitly: пошаговое руководство