Импортёр миграции с TinyURL: как он работает и где пробелы

Импортёр миграции с TinyURL принимает API-токен, целевой домен Elido и стратегию конфликтов, а затем копирует ваши ссылки TinyURL в Elido одной фоновой задачей. У него есть один серьёзный известный дефект: он вызывает GET /aliases на api.tinyurl.com, а этого пути нет в опубликованном API TinyURL. В этой статье - что делает импортёр, что мы проверили и что нет.

Если вам нужно практическое руководство по планированию ухода с TinyURL (что можно перенаправить, соответствие полей в CSV, чек-лист переключения), читайте Миграция с TinyURL. Здесь - инженерная сторона.

Известная ошибка

Запрос страницы в импортёре строится так:

GET https://api.tinyurl.com/aliases?page=1&per_page=100
Authorization: Bearer <token>

и ожидает в ответ {"data": [{alias, url, title, tags}], "meta": {"total", "has_more"}}.

В спецификации OpenAPI TinyURL (данные на 2026-10-02) путь /aliases не определён. Перечисление выполняется через GET /urls/{type}, где type - available или archived, с необязательными фильтрами from, to и search (префикс alias: или tag:). В спецификации нет параметров page и per_page и нет лимитов запросов. Операции с алиасами находятся под /alias/{domain}/{alias}.

Так что контракт пагинации в нашем коде никогда не брался у TinyURL. Наш юнит-тест отдаёт написанный вручную ответ такой формы и проходит, а это доказывает лишь, что парсер соответствует нашему предположению, и ничего не говорит о TinyURL. Мы не запускали импортёр на живом аккаунте TinyURL, потому что для этого нужен токен платного плана. Пока мы этого не сделали, не стройте на нём план миграции. Исправление отслеживается в нашем внутреннем бэклоге: перейти на /urls/available (а /urls/archived - за флагом), листать окнами from/to, разбирать ответ защитно и тестировать на реальном захваченном ответе. Что приходит в реальном ответе, список или одиночный объект, спецификация оставляет неясным.

Что воркер делает после получения страницы

Страница интеграций в DEMO-пространстве с синтетическими данными. Миграция с TinyURL запускается отсюда.

Всё после HTTP-вызова не зависит от вопроса об эндпоинте. Эту часть мы можем описать по коду.

• Старт. POST с token, target_domain_id и необязательным conflict_strategy. Обработчик отклоняет пустой токен, отсутствующий домен и любую стратегию, кроме suffix, skip, fail, затем отвечает 202 с задачей и запускает воркер в фоновой горутине, отделённой от запроса.
• По каждой ссылке. Строка без URL или без алиаса считается неудавшейся с указанием причины. В остальных случаях алиас становится слагом, назначение и заголовок копируются (заголовок обрезается до 200 символов), а теги копируются с добавлением imported:tinyurl.
• Прогресс. Счётчики сбрасываются в строку задачи каждые 50 ссылок. На одну задачу логируется не больше 1000 строк ошибок.
• Ошибки авторизации и лимитов. 401 или 403 завершает задачу неудачей с сообщением "проверьте bearer-токен", а 429 - неудачей по ограничению частоты. Повторных попыток и отката нет: задача останавливается.

Правила конфликтов

Список ссылок в DEMO-пространстве. Импортированные ссылки несут тег imported:tinyurl, поэтому партию можно отфильтровать для проверки.

Перед каждой вставкой воркер делает один индексированный запрос по (domain, slug).

• suffix (по умолчанию) пробует alias-2, alias-3, до alias-50, и помечает строку неудавшейся, если все заняты.
• skip не трогает существующую ссылку Elido и записывает исходную строку в журнал.
• fail завершает задачу неудачей при первом конфликте.

TinyURL называет их алиасами, Elido - слагами. Это одно и то же: символы после хоста. Если целевой домен пуст, алиасы переносятся без изменений.

Лимиты

Один общий набор констант, который используют все вендоры миграции: 50 000 ссылок за запуск, бюджет 30 минут, прогресс каждые 50 ссылок, 1000 записанных ошибок.

Стоит знать о двух особенностях. Когда достигнут лимит в 50 000, цикл просто останавливается, и задача завершается; она не падает и не просит с кем-то связаться. Сравните итоговые счётчики с общим числом в источнике. Когда 30-минутный бюджет исчерпан, задача помечается неудавшейся с указанием числа ссылок, импортированных к этому моменту.

Воркер живёт внутри api-core. Деплой или сбой посреди выполнения убивает его, а проверка, которая запускается каждые пять минут, переводит задачи без прогресса в течение 30 минут в failed. Сохранённого курсора нет, поэтому задачу нужно запускать заново. Повторный запуск безопасен при suffix или skip, хотя при suffix он создаст копии с -2 для ссылок, которые первый запуск уже записал, поэтому для повторного запуска лучше skip.

Обработка токена

Токен идёт из тела запроса в горутину и больше никуда. Строка задачи не записывает токен, и ничего не шифруется при хранении, потому что ничего не хранится. Тело запроса читается с ограничением 4 КБ.

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

Что не переносится

• История кликов. Импортёр читает только поля ссылок. Новые клики считаются с момента, когда ссылка заработала в Elido.
• Оформление QR, шаблоны, настройки брендированного домена. Не читаются. Брендированный хост - отдельный шаг: добавьте его как домен Elido и измените DNS, это описано в материале собственные домены для коротких ссылок.
• Ссылки без аккаунта. Ни один токен не может их перечислить.

Импортёр не создаёт домен за вас, не обрабатывает поле domain TinyURL и не имеет собственной загрузки CSV. Для переноса через файлы используйте форму массового импорта или пошаговое описание в материале массовый импорт из Google Sheets.

Тестирование и обходной путь

Далее два практических раздела. Тестирование импортёра. Перенос без него.

Безопасный способ проверить импорт

Когда эндпоинт исправят, или если вы тестируете импортёр сами до этого, делайте это в малом масштабе. Создайте временное рабочее пространство, добавьте пустой домен и сначала запустите задачу со стратегией fail. Пустой домен означает отсутствие конфликтов, так что любая ошибка - это проблема разбора или авторизации, а не коллизия. Затем сравните три числа: количество в источнике TinyURL, total, которое сообщает задача, и сумму счётчиков импортированных, пропущенных и неудавшихся. Поскольку воркер берёт meta.total из ожидаемого ответа, расхождение между total и вашим реальным числом - первый признак того, что форма ответа отличается от предположений парсера.

Затем отфильтруйте список ссылок по imported:tinyurl и откройте десять случайных ссылок. Сверьте назначение, слаг и заголовок с TinyURL. После этого для любого повторного запуска переключитесь на skip.

Как выгрузить данные из TinyURL без импортёра

Документированный вызов для перечисления - GET /urls/available с bearer-токеном, а для архивных ссылок - GET /urls/archived. Если аккаунт большой, сузьте результат датами from и to, поскольку параметров страниц в спецификации нет. Сначала запишите вывод в файл, затем сократите его до destination, slug, title и загрузите через форму массового импорта. Подробности этого соответствия - в практическом руководстве. Форму живого ответа мы тоже не проверяли, поэтому прежде чем писать скрипт, вручную изучите один ответ.

Что дальше

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

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

• Миграция с TinyURL: что переносится, что остаётся, что ломается
• Миграция с Bitly
• Миграция с Rebrandly
• Миграция с Short.io
• Короткие ссылки как Terraform