Co sprawdzić przy ocenie brokerów API

Zdefiniuj „brokera API” i co się zmienia, gdy z niego korzystasz

Broker API to usługa dostępu do rynku lub wykonywania transakcji, z którą łączysz się programistycznie (za pośrednictwem interfejsu programowania aplikacji) zamiast korzystać z ręcznego interfejsu transakcyjnego. Kluczowa różnica polega na tym, że Twój system staje się odpowiedzialny za przekształcanie Twoich intencji (instrukcji zleceń) w rzeczywiste żądania, obsługę odpowiedzi i reagowanie na błędy.

Aby obiektywnie ocenić brokerów API, potraktuj problem jako dwie warstwy:

1. Mechanika integracji (stabilna, testowalna): jak działa uwierzytelnianie, jak wysyłasz żądania, jak wyglądają odpowiedzi i jak interpretujesz stany zleceń i wykonania.
2. Warunki rynkowe i dostawcy (zmienne): co się dzieje podczas zmiennych cen, częściowej płynności, opóźnień sieciowych oraz reguł i kosztów wykonania po stronie dostawcy.

Jeśli skupisz się tylko na części „API”, możesz przeoczyć najważniejsze niepewności—jakość wykonania i zachowanie operacyjne w warunkach stresu.

Lista kontrolna: mechanika integracji, którą możesz zweryfikować

Zastosuj podejście oparte na dowodach: poproś o dokumentację lub ją sprawdź, a następnie przetestuj na kontrolowanych przykładach.

1. Uwierzytelnianie i zakres konta: Potwierdź, jakie poświadczenia są używane, jak autoryzowany jest dostęp i czy klucze API mogą być ograniczone uprawnieniami (na przykład tylko do odczytu vs. do transakcji).

2. Model żądań/odpowiedzi: Sprawdź, jak API reprezentuje zlecenia—typy zleceń, ważność zlecenia (time-in-force), wymagane pola i dokładną strukturę odpowiedzi. Zdefiniuj, na jakich statusach możesz polegać i które pola mogą być niedostępne podczas przejściowych awarii.

3. Idempotencja i kontrola duplikatów: Określ, jak API zapobiega ponownym zgłoszeniom lub je rozwiązuje (np. ponowne próby po przekroczeniu limitu czasu). Twój system powinien być w stanie unikać przypadkowych zduplikowanych zleceń.

4. Mapowanie cyklu życia zlecenia i wykonania: Zweryfikuj, co oznaczają stany „przyjęte”, „zrealizowane”, „odrzucone”, „anulowane” lub im równoważne. Istotnym ryzykiem jest niespójność statusów—Twój system może uważać, że zlecenie jest aktywne, podczas gdy broker już je odrzucił.

5. Limity zapytań i zachowanie przy ograniczaniu przepustowości: Sprawdź udokumentowane limity i jakie odpowiedzi wskazują na ograniczanie. Zaplanuj, jak Twój kod zachowa się po otrzymaniu sygnałów limitu lub przeciążenia.

6. Produkty danych i znaczniki czasu: Jeśli API udostępnia notowania, transakcje lub zdarzenia konta, wyjaśnij znaczenie znaczników czasu (czas serwera vs. czas lokalny) i założenia dotyczące częstotliwości aktualizacji. Bez tego nie oddzielisz opóźnień od ruchu rynkowego.

7. Obsługa błędów i strategia ponawiania: Potwierdź, jak API komunikuje błędy (HTTP/sieciowe vs. na poziomie aplikacji). Twoje testy powinny klasyfikować awarie na „bezpieczne do ponowienia”, „ponów z idempotencją” i „nie ponawiaj”.

Dowody i przykłady: jak testować bez zakładania wyników

Ponieważ wyniki różnią się w zależności od warunków, używaj testów mierzących zachowanie Twojego systemu.

• Test integracyjny czarnej skrzynki: Wyślij niewielką liczbę dobrze zdefiniowanych zleceń i potwierdź, że Twój wewnętrzny automat stanów odpowiada raportowanemu przez API cyklowi życia.
• Symulacja limitu czasu i ponawiania (z podanym założeniem): Załóż, że Twoje wywołanie sieciowe może przekroczyć limit czasu po danym progu (wybierz próg dla swojego środowiska). Następnie zweryfikuj, czy ponawianie powoduje duplikaty, czy też klucze idempotencji (jeśli są obsługiwane) zapobiegają powtórzeniom.
• Scenariusz częściowej realizacji (z podanym założeniem): Załóż, że rynek może nie w pełni zaspokoić Twojego wolumenu. Przetestuj, jak wykrywasz pozostałą ilość i jak dostarczane są kolejne aktualizacje.
• Kontrola kolejności zdarzeń: Zarejestruj sekwencję wywołań zwrotnych/zdarzeń API i porównaj ją z tym, czego oczekuje Twój kod. Jednym z trybów awarii są aktualizacje poza kolejnością, które mogą zepsuć założenia w śledzeniu zleceń.

Dla każdego testu rejestruj: identyfikatory żądań, znaczniki czasu (ze strefą czasową/źródłem), treści odpowiedzi i końcowe wyniki uzgodnień.

Ograniczenia i ryzyka: co najmniej jeden istotny tryb awarii

Istotne ograniczenia mają zastosowanie nawet wtedy, gdy dokumentacja wygląda jasno:

• Awarie operacyjne: Przerwy w sieci, przestoje API lub degradacja usługi mogą powodować brak odpowiedzi lub opóźnione aktualizacje statusów. Twoja automatyzacja musi działać bezpiecznie w warunkach niepewności.
• Częściowe realizacje i zmienność wykonania: Nawet przy poprawnej integracji rzeczywiste realizacje zależą od dostępnej płynności i mechaniki wykonania w danym momencie.
• Niezgodność statusów (istotny tryb awarii): Twój system może pokazywać zlecenia „w trakcie realizacji”, podczas gdy broker je odrzucił lub anulował. Może się to zdarzyć po przekroczeniu limitów czasu, ponowieniach lub niespójnym dostarczaniu zdarzeń.
• Niepewność kosztów i poślizgu: Wyniki wykonania mogą różnić się od historycznych zależności, ponieważ koszty i jakość wykonania zmieniają się wraz z warunkami.

Dlatego celem oceny nie jest przewidywanie, ale umiejętność uzgodnienia tego, co się wydarzyło i wykrywania niezgodności.

Weryfikacja i kolejne pytania przed automatyzacją

Zanim zaczniesz polegać na automatyzacji API, wymagaj jasnej, niezależnie weryfikowalnej odpowiedzi na następujące pytania: