Alternatywa dla API Bitly dla deweloperów: na co zwrócić uwagę

Jeśli szukasz alternatywy dla API Bitly, prawdopodobnie natrafiłeś na jedną z dwóch ścian: limity żądań ograniczające Twoją automatyzację na planie, na który Cię stać, albo potrzebną funkcję ukrytą za poziomem, którego nie chcesz kupować. To przewodnik dla deweloperów po tym, co naprawdę liczy się w API skracacza - limity, idempotencja, webhooki, SDK - oraz jak w praktyce wygląda zmiana.

Ten wpis należy do klastra engineering. Po kształt żądania i podstawy uwierzytelniania wspólne dla wszystkich tych rozwiązań sięgnij po przewodnik po darmowym API skracacza URL - to podstawa, na której buduje ten tekst.

Gdzie boli API Bitly

API Bitly jest wydajne i przy niskim wolumenie sprawdza się dobrze. Tarcie pojawia się przy skali. Limity żądań sięgają od około 1000 żądań miesięcznie na najniższych poziomach do 150 000+ wyżej, z dodatkowymi limitami na minutę i na godzinę, udokumentowanymi w dokumentacji referencyjnej API Bitly. Na tańszym planie te limity ograniczają dokładnie te zautomatyzowane zadania, do których API jest przeznaczone.

Drugą ścianą jest blokowanie funkcji. Struktura grup i organizacji, niektóre endpointy analityczne oraz wyższe wolumeny wywołań znajdują się na wyższych poziomach, więc wersja API, na którą możesz uzasadnić budżet, często nie jest wersją, jaką zakładała Twoja integracja. Żadne z tych zjawisk nie jest ściśle wadą - tak zbudowany jest cennik - ale oba są powodem, dla którego zespoły zaczynają się rozglądać. Własny rozbiór API Bitly autorstwa Rebrandly dochodzi do tego samego wniosku co do tego, gdzie uwierają limity.

Co powinno dać Ci API skracacza stawiającego na deweloperów

Odejmij markę, a dobre API skracacza sprowadza się do czterech rzeczy.

1. Limity żądań, wokół których można planować. Udokumentowane limity w danym oknie czasowym, przypisane do workspace'u, nie tak ciasne na poziomach podstawowych, by zadanie wsadowe je przekraczało. Przewidywalność bije wysokie, ale nieprzejrzyste limity.
2. Klucze idempotencji. Wysyłasz stały klucz na logiczne żądanie, a ponowienie po przekroczeniu czasu zwraca oryginalny link zamiast tworzyć duplikat. Bez tego każde ponowienie to ryzyko.
3. Webhooki. Zdarzenia kliknięć trafiają do Twojego endpointu zamiast zmuszać Cię do odpytywania API analitycznego w pętli czasowej.
4. Prawdziwe SDK. Oficjalne biblioteki w językach, których używasz, więc nie musisz ręcznie pisać uwierzytelniania i paginacji.

Dogłębna analiza limitów żądań i idempotencji wyjaśnia, dlaczego drugi punkt liczy się bardziej niż surowy limit żądań: API bezpieczne przy ponowieniach na poziomie 10 000 żądań bije kruche API na poziomie 100 000.

Migracja jest mniejsza, niż myślisz (poza jedną częścią)

Wywołanie API prawie się nie zmienia. Wywołanie tworzenia linku w Bitly i większość alternatyw mają ten sam kształt: uwierzytelniasz się tokenem typu Bearer, wysyłasz długi adres URL metodą POST, odczytujesz krótki link z JSON-a. Zmiana dostawcy to głównie nowy bazowy adres URL, nowy token i dopasowanie nazw pól.

# 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"}'

Jeśli wywołujesz to z poziomu kodu, przewodnik po Pythonie pokazuje wzorce ponowień i idempotencji, jakich chcesz użyć wokół każdego z tych wywołań.

Częścią, która nie jest mała, są Twoje istniejące linki. Krótki link działa dalej tylko wtedy, gdy kontrolujesz domenę, na której się znajduje. Linków na bit.ly nie da się przenieść - ta domena należy do Bitly. Tylko linki marki na Twojej własnej domenie można przekierować do nowego dostawcy bez ich zepsucia. Prawdziwe pytanie migracyjne brzmi więc: „ile z moich działających linków znajduje się na domenie, którą posiadam?” - a odpowiedź decyduje o tym, jak czysta będzie zmiana. Przewodnik migracji z Bitly prowadzi przez kroki dotyczące domeny i przekierowań.

Wybór jednego

Uczciwa krótka lista dla API dla deweloperów to Short.io, Rebrandly, Dub i Elido - każdy udostępnia prawdziwe API z SDK. Short.io i Dub stawiają na cenę przyjazną deweloperom; Rebrandly stawia na automatyzację domen marki. Tam, gdzie Elido się różni, to kombinacja, na której inni się nie skupiają: idempotencja i webhooki jako domyślne ustawienia, plus rezydencja danych w UE, dzięki czemu dane o kliknięciach zostają w regionie UE zamiast być transferowane na zewnątrz. Jeśli Twój stack ma linię zgodności obok linii technicznej, to połączenie jest powodem, by się temu przyjrzeć - a Ty możesz budować na tym API na planie darmowym, by sprawdzić dopasowanie przed podjęciem decyzji.

Cokolwiek wybierzesz, oceniaj to na podstawie limitów i idempotencji, a nie marketingu. To te dwie rzeczy decydują o tym, czy Twoja integracja jest nudna i niezawodna, czy źródłem alertów o drugiej w nocy.

Przeczytaj serię cornerstone

Ten wpis należy do klastra engineering. Zacznij od przewodnika po darmowym API skracacza URL, a następnie przejdź do dogłębnej analizy limitów żądań i idempotencji. Żywym odniesieniem jest dokumentacja API.

Powiązane wpisy na blogu

• Darmowe API skracacza URL: kształt żądania, uwierzytelnianie i limity
• Limity żądań i idempotencja API skracacza URL
• Jak skrócić adres URL w Pythonie
• Przewodnik po alternatywach wypełniających luki funkcjonalne Bitly
• Migracja z Bitly: przewodnik