Wyjaśnienie limity zapytań w API giełdy krypto
1. Co oznaczają „limity liczby zapytań w API”
Limity liczby zapytań w API są proste w teorii. Określają maksymalną liczbę żądań, jaką giełda zaakceptuje w danym oknie czasowym, na przykład w ciągu 1 sekundy, 1 minuty albo 1 godziny. To właśnie jest sedno wyjaśnienia limitów liczby zapytań w API giełd krypto, czyli temat, który często opisuje się też jako rate limit API kryptowalut.
Nie myl limitów z opłatami. Opłata to koszt naliczany za transakcję, wypłatę albo poziom usługi. Limit to zasada ruchu. Jeśli Twój klient wyśle 200 żądań w minutę, a giełda pozwala tylko na 120, 121. żądanie może się nie powieść, nawet jeśli konto jest darmowe.
Limity różnią się też od poziomów konta. Niektóre giełdy przyznają większe limity użytkownikom zweryfikowanym, market makerom albo w płatnych planach, ale sam limit nadal istnieje. Jeden poziom może pozwalać na 10 zapytań na sekundę, a inny na 50. Giełda nadal stawia granicę.
Praktycznie można to ująć tak: limity są zasadami wejścia do API. Możesz zostać wpuszczony, ale nie wszystko naraz. W gorące dni ma to duże znaczenie.
2. Dlaczego giełdy stosują limity
Giełdy stosują limity z trzech prostych powodów: żeby chronić infrastrukturę, ograniczać nadużycia i utrzymywać stabilność systemów podczas skoków ruchu. Rynek może zmienić się bardzo szybko w 30 sekund, a zalew skryptów może jednocześnie obciążyć arkusze zleceń, sprawdzanie salda i feedy cenowe. Jeśli jeden klient wysyła zbyt wiele wywołań, odczuwa to każdy.
Jest też kwestia uczciwości. Bez limitów jeden agresywny bot mógłby zasypywać publiczne endpointy i wypierać mniejszych użytkowników. To nie teoria; taki problem pojawia się przy nowych notowaniach albo gwałtownej wyprzedaży, gdy liczba żądań rośnie ponad normę.
Niektóre limity mają powstrzymywać scrapowanie, nadużycia albo przypadkowe pętle. Zła pętla może wysłać to samo żądanie 500 razy, zanim ktoś to zauważy. Giełda widzi wtedy sztorm, nie wypadek.
Warto jednak pamiętać, że limity nie służą wyłącznie obronie. Pomagają giełdom utrzymywać świeże dane rynkowe i responsywne systemy zleceń, gdy ruch rośnie. Stabilne API łatwiej zaufać niż takiemu, które ugina się pod nagłym napływem.
3. Jak mierzy się limity
Większość giełd mierzy limity w liczbie zapytań na sekundę albo na minutę. Inne stosują system mieszany: mały limit na sekundę i większy na minutę. Giełda może też przypisywać różną wagę różnym endpointom. Prosty odczyt ceny może liczyć się jako 1 jednostka, a złożenie zlecenia albo zapytanie o historię jako więcej.
Limity zależne od endpointu są bardzo częste. Publiczny endpoint tickerów może pozwalać na więcej wywołań niż prywatny endpoint salda. Oddzielne limity dla publicznych i uwierzytelnionych wywołań również pojawiają się często.
Niektóre API pozwalają na krótkie skoki ruchu. Oznacza to, że możesz wysłać przez kilka sekund krótki pakiet żądań powyżej stałego tempa, o ile średnia nadal mieści się w regule. Inne są sztywne i płaskie, bez żadnego marginesu na burst. Ta różnica zmienia sposób pisania klienta.
Szukaj jednostki, okna czasowego i wagi. Te trzy liczby mówią prawie wszystko. Strona, która mówi tylko „ograniczenie liczby zapytań”, to za mało.
4. Gdzie limity ujawniają się w realnych workflowach
Limity najpierw wychodzą na jaw przy zwykłych zadaniach. Trader odświeżający ceny co 2 sekundy może szybko dobić do sufitu, jeśli aplikacja sprawdza 20 rynków naraz. Programista synchronizujący salda co 5 sekund może na początku działać bez problemu, a potem nagle zobaczyć błędy, gdy lista portfeli urośnie z 3 aktywów do 30.
Także składanie zleceń jest punktem nacisku. Bot, który testuje sygnały, anuluje nieaktualne zlecenia i wysyła nowe, może bardzo szybko wyczerpać budżet zapytań, zwłaszcza przy dużej zmienności. Jedną minutę system wydaje się spokojny. A 12 tików później już nie jest.
Backfill danych historycznych łatwo przecenić. Pobieranie 90 dni świec, historii transakcji albo filli często oznacza tysiące żądań, a każde z nich konkuruje z ruchem na żywo, jeśli giełda nie oferuje endpointu zbiorczego. Jeśli API zwraca tylko 100 wierszy na wywołanie, matematyka szybko robi się nieprzyjemna.
Polling to ukryty podatek od czasu, nie od pieniędzy. Panel, który sprawdza pięć endpointów co sekundę, może wyglądać niewinnie podczas testów, a potem przeciążyć limit, gdy dołączą realni użytkownicy. Dlatego wiele zespołów po pierwszym trudnym miesiącu przechodzi z pollingu na websockety.
5. Typowe sygnały ostrzegawcze i tryby awarii
Najbardziej oczywistym sygnałem jest błąd HTTP, często status 429 oznaczający zbyt wiele żądań; w praktyce to właśnie błąd 429 w API giełdy, z którym integracje spotykają się najczęściej. Niektóre giełdy zwracają jasny komunikat. Inne dają ogólny błąd i oczekują, że klient odczyta nagłówki. Niezbyt przyjemne, ale powszechne.
Innym skutkiem jest tymczasowe ograniczanie tempa. API może zacząć spowalniać odpowiedzi, zanim w ogóle odmówi wywołań. Wysyłasz żądanie, a potem czekasz 1,5 sekundy na odpowiedź, która wcześniej przychodziła po 120 milisekundach. To opóźnienie jest ostrzeżeniem przed blokadą.
Niektóre platformy nakładają okno bana po wielokrotnym naruszeniu zasad. Ban może trwać 30 sekund, 5 minut albo dłużej. W poważnych przypadkach giełda może zablokować adres IP albo klucz API. Jeśli bot bezmyślnie ponawia próby, kara staje się większa.
Odrzucenia zleceń mogą też wystąpić bez eleganckiego komunikatu o limicie. Żądanie handlowe może się nie powieść, bo klient już wykorzystał dostępny przydział burstu, choć to samo konto nadal może pobierać dane publiczne. Ta rozbieżność często myli zespoły przy pierwszej integracji.
6. Jak czytać zasady limitów giełdy
Zacznij od dokumentacji, ale nie zatrzymuj się na pierwszej tabeli. Szukaj wag endpointów, zasad cooldownu i uwag o wyjątkach. Na stronie może widnieć „10 zapytań na sekundę”, a gdzieś niżej dopiero informacja, że endpointy zleceń liczą się jako waga 5 każdy. To bardzo zmienia realną przepustowość.
Nagłówki mają znaczenie. Wiele giełd zwraca w odpowiedzi nagłówki związane z limitami, a te nagłówki często pokazują, ile zapytań zostało, kiedy nastąpi reset albo czy bieżące wywołanie zużyło dodatkową wagę. Jeśli dokumentacja jest ogólna, nagłówki zwykle są mniej ogólne.
Zwracaj uwagę na ukryte wyjątki. Publiczne dane rynkowe mogą mieć jedną zasadę, a prywatne wywołania handlowe inną. Połączenia websocket również mogą mieć osobne limity połączeń. Jeśli czytasz tylko pierwszy akapit, możesz przeoczyć właśnie ten fragment, który sprawia problem.
Zespoły często trzymają prostą checklistę przed integracją. Jeśli chcesz szerszej listy kontrolnej przed startem, artykuł o checkliście bezpieczeństwa giełdy krypto będzie dobrym uzupełnieniem, bo błędy limitów i błędy bezpieczeństwa często pojawiają się razem, gdy klucz API zostanie ujawniony albo użyty niewłaściwie.
Zwróć też uwagę na język dokumentacji. Krótkie sformułowania mogą ukrywać realne ograniczenia. Jeśli na stronie jest „fair use”, poproś o konkretną liczbę. Jeśli widzisz „może ulec zmianie”, zapytaj, kto to zmienia i jak często. To ważne przed wdrożeniem, nie po awarii.
7. Terminy związane z limitami, które warto znać
Throttle oznacza, że giełda celowo spowalnia Twój ruch. To jeszcze nie awaria, ale już blisko. Nadal możesz otrzymywać odpowiedzi, tylko później niż zwykle.
Quota to całkowity przydział na dany okres. Jeśli quota wynosi 100 zapytań na minutę, ta liczba resetuje się po zamknięciu okna minutowego. Quota to budżet. Wydawaj go rozsądnie.
Burst allowance to krótki dodatkowy margines, jaki API może przyznać. Burst 20 zapytań może być w porządku, nawet jeśli stałe tempo wynosi 5 na sekundę. Warunek jest taki, że średnia nadal musi pasować do reguły.
Backoff to pauza przed kolejną próbą. Klient, który odczekuje 250 milisekund, potem 500 milisekund, potem 1 sekundę, zachowuje się jak cierpliwa osoba. Klient, który ponawia natychmiast, zachowuje się jak uszkodzony.
Okno bana oznacza okres, w którym giełda blokuje kolejne żądania po naruszeniu zasad. Weighted requests to wywołania, które liczą się jako więcej niż 1 jednostka. Jeśli jeden endpoint ma wagę 10, to 10 takich wywołań może zużyć tyle samo przydziału, co 100 lekkich wywołań. To właśnie ten szczegół potrafi zepsuć bota o 3:00 nad ranem.
8. Przykłady: typowe scenariusze limitów
Przykład 1: aplikacja sprawdzająca ceny. Załóżmy, że aplikacja obserwuje 8 par i odświeża je co 5 sekund. Brzmi lekko, ale jeśli każde odświeżenie trafia w osobny publiczny endpoint, a giełda pozwala tylko na 10 zapytań na sekundę, aplikacja może działać dobrze aż do momentu, gdy dołączą kolejni użytkownicy i ten sam serwer zacznie obsługiwać 50 sesji. Wtedy limit staje się widoczny.
Przykład 2: bot tradingowy. Bot sprawdza sygnały, składa zlecenia, anuluje przestarzałe zlecenia i potwierdza fill’e. Jeśli każda akcja używa uwierzytelnionych endpointów z cięższą wagą, bot może dojść do limitu już po kilku szybkich cyklach. Ostrożny bot korzysta z cache’owanego stanu, rzadziej sprawdza saldo i stosuje opóźnienie retry, które rośnie po każdym błędzie.
Przykład 3: zadanie masowego pobierania danych. Skrypt badawczy pobierający 180 dni danych świec może uruchomić limity długo przed zakończeniem. Jeśli giełda zwraca tylko 200 wierszy na żądanie, zadanie może wymagać setek wywołań. Lepsze podejście to dzielenie po dniach, przerwy między porcjami i wznowienie od ostatniego poprawnego znacznika czasu po błędzie.
Jeśli porównujesz platformy pod kątem takich przypadków, wybór giełdy ma znaczenie równie duże jak kod. Praktyczny przewodnik, taki jak jak wybrać giełdę kryptowalut, pomaga zdecydować, czy projekt API pasuje do Twojego workflow, a nie tylko czy interfejs handlowy wygląda dobrze.
Warto też wspomnieć o drugim rodzaju przykładu: API, które wygląda czysto, ale źle zachowuje się pod obciążeniem. Niektóre projekty działają dobrze w sandboxie, a potem zawodzą na produkcyjnych endpointach, bo zasady limitów są tam ostrzejsze. Dlatego same dane testowe nigdy nie wystarczą.
Jeszcze jedna praktyczna uwaga. Jeśli próbujesz chronić klienta przed banami, lektura o jak zweryfikować giełdę kryptowalut pomoże sprawdzić, czy platforma publikuje jasne zasady, dane kontaktowe do wsparcia i spójne zachowanie API, zanim zaufasz jej ruchem na żywo.
Dla czytelników budujących boty albo dashboardy najczystsze rozwiązanie to zwykle nie „wysyłaj szybciej”. To „wysyłaj mniej”. Buforuj wyniki przez 3 sekundy, nie dubluj wywołań i nie pytaj o to samo saldo dwa razy w jednym cyklu. Taka dyscyplina utrzymuje API w spokoju i logi w czytelności.
Na koniec jedna uwaga: jeśli strona dokumentacji jest tak niejasna, że nie potrafisz stwierdzić, czy jedno żądanie kosztuje 1 jednostkę, czy 5, potraktuj to jako ostrzeżenie, a nie zagadkę. Zapytaj support o dokładny limit, okno resetu i karę za przekroczenie. To nie są ozdobniki; od nich zależy, czy integracja przetrwa swój pierwszy intensywny okres.
