Importer migracji z TinyURL: jak działa i jakie ma luki

Importer migracji z TinyURL przyjmuje token API, docelową domenę Elido i strategię konfliktów, a następnie kopiuje Twoje linki z TinyURL do Elido jako jedno zadanie w tle. Ma jeden poważny znany defekt: wywołuje GET /aliases na api.tinyurl.com, a tej ścieżki nie ma w opublikowanym API TinyURL. Ten wpis omawia, co importer robi, co zweryfikowaliśmy, a czego nie.

Jeśli chcesz przewodnik po planowaniu przeprowadzki z TinyURL (co można przekierować, mapowanie CSV, lista kontrolna przełączenia), przeczytaj Migracja z TinyURL. To jest strona inżynierska.

Znany błąd

Pobranie strony przez importer buduje to żądanie:

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

i oczekuje w odpowiedzi {"data": [{alias, url, title, tags}], "meta": {"total", "has_more"}}.

Specyfikacja OpenAPI TinyURL (dostęp 2026-10-02) nie definiuje ścieżki /aliases. Listowanie to GET /urls/{type}, gdzie type to available lub archived, z opcjonalnymi filtrami from, to i search (prefiks alias: lub tag:). Specyfikacja nie definiuje parametrów page ani per_page ani limitów szybkości. Operacje na aliasach znajdują się pod /alias/{domain}/{alias}.

Kontrakt stronicowania w naszym kodzie nigdy więc nie został wzięty z TinyURL. Nasz test jednostkowy serwuje odpowiedź napisaną ręcznie w tym kształcie i przechodzi, co dowodzi, że parser pasuje do naszego założenia, a o TinyURL nie mówi nic. Nie uruchamialiśmy importera na żywym koncie TinyURL, bo wymaga to tokena z płatnego planu. Dopóki tego nie zrobimy, nie planuj migracji w oparciu o niego. Poprawka jest śledzona w naszym wewnętrznym backlogu: przejść na /urls/available (i /urls/archived za flagą), stronicować oknami from/to, parsować defensywnie i testować na prawdziwej przechwyconej odpowiedzi. To, czy prawdziwa odpowiedź niesie listę, czy pojedynczy obiekt, specyfikacja pozostawia niejasne.

Co worker robi po otrzymaniu strony

Strona integracji w workspace DEMO z danymi syntetycznymi. Migracja z TinyURL jest uruchamiana stąd.

Wszystko po wywołaniu HTTP jest niezależne od kwestii endpointu. Tę część możemy stwierdzić na podstawie kodu.

• Start. POST z token, target_domain_id i opcjonalnym conflict_strategy. Handler odrzuca pusty token, brakującą domenę i każdą strategię spoza suffix, skip, fail, po czym odpowiada 202 z zadaniem i uruchamia workera w goroutine w tle, oderwanej od żądania.
• Na link. Wiersz bez URL lub bez aliasu jest liczony jako nieudany z podaniem przyczyny. W przeciwnym razie alias staje się slugiem, cel i tytuł są kopiowane (tytuł obcięty do 200 znaków), a tagi są kopiowane z dołączonym imported:tinyurl.
• Postęp. Liczniki są zapisywane w wierszu zadania co 50 linków. Na zadanie logowanych jest najwyżej 1000 wierszy błędów.
• Błędy uwierzytelniania i limitów. 401 lub 403 kończy zadanie błędem z komunikatem "check the bearer token", 429 kończy je jako ograniczone limitem szybkości. Nie ma ponawiania ani wycofywania: zadanie się zatrzymuje.

Reguły konfliktów

Lista linków w workspace DEMO. Zaimportowane linki niosą tag imported:tinyurl, więc możesz przefiltrować partię do przeglądu.

Przed każdym wstawieniem worker wykonuje jedno indeksowane wyszukiwanie po (domain, slug).

• suffix (domyślna) próbuje alias-2, alias-3, aż do alias-50, a jeśli wszystkie są zajęte, oznacza wiersz jako nieudany.
• skip zostawia istniejący link Elido w spokoju i loguje wiersz źródłowy.
• fail kończy zadanie błędem przy pierwszym konflikcie.

TinyURL nazywa je aliasami, Elido nazywa je slugami. To to samo: znaki po hoście. Jeśli Twoja domena docelowa jest pusta, aliasy przenoszą się bez zmian.

Limity

Jeden wspólny zestaw stałych, używany przez wszystkich dostawców migracji: 50 000 linków na uruchomienie, budżet 30 minut, postęp co 50 linków, 1000 zalogowanych błędów.

Warto znać dwa zachowania. Gdy limit 50 000 zostanie osiągnięty, pętla po prostu się zatrzymuje, a zadanie się kończy; nie kończy się błędem i nie każe się z nikim kontaktować. Porównaj końcowe liczby z sumą w źródle. Gdy skończy się budżet 30 minut, zadanie jest oznaczane jako nieudane z liczbą dotychczas zaimportowanych.

Worker mieszka wewnątrz api-core. Deploy lub awaria w trakcie uruchomienia go zabija, a sprzątanie działające co pięć minut zmienia zadania bez postępu przez 30 minut na failed. Nie ma zapisanego kursora, więc zadanie uruchamiasz od nowa. Ponowne uruchomienie jest bezpieczne przy suffix lub skip, choć przy suffix utworzy kopie z -2 linków, które pierwsze uruchomienie już zapisało, więc przy ponowieniu wybierz skip.

Obsługa tokena

Token trafia z ciała żądania do goroutine i nigdzie indziej. Wiersz zadania nie zapisuje żadnego tokena, a nic nie jest szyfrowane w spoczynku, bo nic nie jest przechowywane. Ciało żądania jest czytane z limitem 4 KB.

Czego kod nie robi: nie waliduje tokena przed startem i nie sprawdza planu. Zły token objawia się jako nieudane zadanie po pierwszym żądaniu, a nie jako błąd formularza. Wcześniejsze wersje tego wpisu opisywały krok wstępnej weryfikacji względem endpointu domen. Tego kroku nie ma w kodzie, a specyfikacja TinyURL też nie ma takiej ścieżki.

Co nie jest migrowane

• Historia kliknięć. Importer czyta tylko pola linków. Nowe kliknięcia liczą się od chwili, gdy link działa w Elido.
• Stylizacja QR, szablony, ustawienia domeny markowej. Nieodczytywane. Markowy hostname to osobny krok: dodaj go jako domenę Elido i zmień DNS, co opisują domeny niestandardowe dla krótkich linków.
• Linki bez konta. Żaden token nie może ich wylistować.

Importer nie tworzy domeny za Ciebie, nie obsługuje pola domain z TinyURL i nie ma własnego wgrywania CSV. Do przeprowadzek opartych na plikach użyj formularza importu zbiorczego lub poradnika w imporcie zbiorczym z Arkuszy Google.

Testowanie i obejście

Poniżej dwie praktyczne sekcje. Testowanie importera. Przeprowadzka bez niego.

Bezpieczny sposób sprawdzenia importu

Gdy endpoint zostanie naprawiony, albo jeśli sam testujesz importer wcześniej, rób to na małą skalę. Utwórz tymczasowy workspace, dodaj pustą domenę i najpierw uruchom zadanie ze strategią fail. Pusta domena oznacza brak konfliktów, więc każda porażka to problem z parsowaniem lub uwierzytelnianiem, a nie kolizja. Następnie porównaj trzy liczby: liczbę w źródle w TinyURL, total raportowane przez zadanie oraz liczniki zaimportowanych plus pominiętych plus nieudanych. Ponieważ worker bierze meta.total z oczekiwanej odpowiedzi, rozbieżność między total a Twoją prawdziwą liczbą jest pierwszym znakiem, że kształt odpowiedzi różni się od tego, co zakłada parser.

Potem przefiltruj listę linków po imported:tinyurl i otwórz losowo dziesięć linków. Sprawdź cel, slug i tytuł względem TinyURL. Potem przy każdym ponowieniu przełącz się na skip.

Jak wyeksportować z TinyURL bez importera

Udokumentowane wywołanie listujące to GET /urls/available z tokenem bearer oraz GET /urls/archived dla zarchiwizowanych linków. Zawęż wynik datami from i to, jeśli konto jest duże, bo specyfikacja nie podaje parametrów stron. Zapisz wynik do pliku, zanim zrobisz cokolwiek innego, zredukuj go do destination, slug, title i wczytaj formularzem zbiorczym. Szczegóły tego mapowania są w przewodniku. Nie zweryfikowaliśmy też kształtu żywej odpowiedzi, więc obejrzyj jedną odpowiedź ręcznie, zanim zaczniesz pisać skrypt.

Co dalej

Kolejność jest taka: naprawić endpoint, dodać prawdziwą przechwyconą odpowiedź jako fixture testowy, a potem ponownie sprawdzić każdą liczbę w przewodniku i na stronie docelowej migracji. Stronicowanie i prawdziwy limit na żądanie wymagają ponownego zmierzenia na żywym koncie, bo specyfikacja nie podaje żadnego. Jeśli musisz opuścić TinyURL wcześniej, porównaj opcje w Elido vs TinyURL i alternatywach dla TinyURL i użyj drogi przez CSV.

Powiązane na blogu

• Migracja z TinyURL: co się przenosi, co zostaje, co się psuje
• Wdrożenie migracji z Bitly
• Wdrożenie migracji z Rebrandly
• Wdrożenie migracji z Short.io
• Krótkie linki jako Terraform