Co sprawdzić przy ocenie dostępu API
Zdefiniuj dostęp API w praktycznych kategoriach
Dostęp API oznacza interfejs programowy, który umożliwia jednemu systemowi żądanie danych lub działań od innego systemu poprzez wysyłanie ustrukturyzowanych żądań i otrzymywanie ustrukturyzowanych odpowiedzi. W kontekście handlu lub danych rynkowych zwykle obejmuje to uwierzytelnianie (udowodnienie, że masz prawo się połączyć), autoryzację (co masz prawo robić) oraz wymianę danych (kwotowania, zlecenia, pozycje lub informacje związane z kontem).
Oceniając dostęp API, rozdziel dwie rzeczy:
- Stabilna mechanika: jak działa interfejs (przepływ żądań/odpowiedzi, formaty, limity, znaczniki czasu).
- Zmienne warunki: jak dobrze działa w przypadku Twojego konkretnego zastosowania (opóźnienie sieciowe, dostępność dostawcy, zachowanie wykonania oraz wszelkie ograniczenia jurysdykcyjne lub polityczne).
Częstym błędem jest traktowanie jednej przykładowej odpowiedzi lub jednej działającej integracji jako dowodu, że API będzie zachowywać się tak samo przy wyższym użyciu, podczas awarii lub gdy rynek porusza się szybko.
Co zweryfikować technicznie (lista kontrolna integracji)
Zacznij od szczegółów „instalacyjnych”, które zwykle decydują o powodzeniu integracji:
- Uwierzytelnianie i autoryzacja
- Potwierdź metodę uwierzytelniania oraz sposób przechowywania i rotacji poświadczeń.
- Zweryfikuj, jakie uprawnienia ma klucz API/token (na przykład, czy może tylko odczytywać dane rynkowe, czy także zarządzać zleceniami i danymi konta).
- Zakres danych i żądań
- Określ dokładnie, które pola danych są dostępne i czy odpowiadają Twoim potrzebom.
- Sprawdź, czy odpowiedzi zawierają informacje o czasie i w jakiej podstawie czasowej (na przykład czas serwera vs. Twój czas lokalny).
- Formaty wiadomości i schematy
- Zweryfikuj strukturę żądań i odpowiedzi (nazwy pól, typy, pola wymagane vs. opcjonalne).
- Potwierdź, jak reprezentowane są paginacja, filtrowanie i przetwarzanie wsadowe.
- Limity zapytań i ograniczanie przepustowości
- Sprawdź udokumentowane limity zapytań i sposób, w jaki API sygnalizuje ich przekroczenie.
- Upewnij się, że Twój klient może wycofać się, bezpiecznie ponowić próbę i uniknąć przypadkowych burz żądań.
- Obsługa zleceń i stanu (jeśli dotyczy)
- W przypadku API związanych z handlem potwierdź, jak system raportuje potwierdzenia zleceń, realizacje, odrzucenia i zmiany.
- Zdefiniuj, jak uzgadniasz „stan pożądany” ze „stanem raportowanym”, gdy aktualizacje przychodzą w nieodpowiedniej kolejności.
Dowód lub dokument, którego należy szukać: jasna dokumentacja API określająca endpointy, schematy, kody błędów i limity. Bez tego nie możesz niezależnie zweryfikować, jak zachowuje się interfejs.
Przetestuj zachowanie na przykładach, które możesz odtworzyć
Aby zamienić dokumentację w dowód, przeprowadź kontrolowane testy z jawnymi założeniami:
- Załóż bazowe opóźnienie sieciowe i wyślij znaną sekwencję żądań.
- Rejestruj znaczniki czasu żądań, znaczniki czasu odpowiedzi i identyfikatory korelacji (jeśli są dostarczane).
- Sprawdź, czy to samo wejście daje spójne kształty wyjścia, nawet jeśli wartości się zmieniają.
Materiałowy tryb awarii, którego należy aktywnie szukać:
- Częściowa awaria: API może zwrócić sukces dla jednego żądania, ale nie powieść się dla kolejnego, lub może zaakceptować żądanie i później zgłosić błąd poprzez aktualizacje asynchroniczne. Twój system musi obsługiwać rozbieżności między tym, czego oczekiwałeś, a tym, co raportuje API.
Przetestuj również:
- Odpowiedzi o błędach: jak API odpowiada na nieprawidłowe parametry, wygasłe uwierzytelnianie lub przekroczone limity?
- Ponowne połączenie: co się dzieje po chwilowym przerwaniu sieci?
- Idempotentność: jeśli ponowisz żądanie, czy tworzy duplikaty, czy bezpiecznie unika podwójnych działań?
Ograniczenia i ryzyka do rozważenia
Ocena dostępu API powinna obejmować niepewność co do realiów operacyjnych:
- Dostępność i opóźnienia są zmienne: interfejs może działać idealnie w testach, a mimo to ulegać degradacji pod obciążeniem lub w okresach incydentów.
- Warunki rynkowe mogą się zmieniać: wyższa zmienność może zwiększyć znaczenie prawidłowej obsługi czasu i solidnego odzyskiwania po błędach.
- Koszty i zużycie zasobów mogą mieć zastosowanie: wiele API ma ograniczenia oparte na użyciu (limit zapytań, przepustowość lub oddzielne poziomy), które mogą wpływać na wydajność i dostępność dla Twojego obciążenia.
Ograniczenie niezależne od czasu: historyczne zachowanie nie gwarantuje przyszłych wyników. Dlatego traktuj testy jako dowód bieżącego zachowania tylko przy Twoich zdefiniowanych założeniach i warunkach.
Kryteria weryfikacji i kolejne pytania
Użyj listy kontrolnej „gotowe do weryfikacji”, na którą możesz odpowiedzieć bez polegania na obietnicach:
- Czy możesz przypisać każdą z wymaganych funkcji (odczyt danych, odczyt konta, zarządzanie zleceniami) do konkretnych udokumentowanych endpointów i uprawnień?
- Czy możesz opisać na podstawie dokumentacji dokładne limity zapytań oraz oczekiwane sygnały ograniczania i błędów?
- Czy możesz wyjaśnić, jak uzgodnisz stan, gdy aktualizacje są opóźnione, przychodzą w nieodpowiedniej kolejności lub są sprzeczne z wcześniejszymi założeniami?
- Czy masz plan obsługi błędów dla ponowień, idempotentności i częściowych awarii?