Ottobre 2026

Monitoraggio di catene API HTTP: perché un 200 su /health non prova che la Sua API funziona

Percorsi

Il monitoraggio di catene API HTTP verifica ciò che un client fa davvero: accedere, ottenere un token, chiamare una route protetta. Un 200 su /health non prova nulla di tutto questo.

Il 200 che mente

Una route /health risponde 200 appena il processo è attivo. Non passa né dall’autenticazione, né dal database, né dalle route che i Suoi clienti chiamano. Il check resta verde mentre l’API rifiuta tutti.

• Il login restituisce un token già scaduto, o firmato con una chiave che è cambiata.
• La route protetta risponde 401 a tutte le chiamate dopo un deploy.
• La risposta è un 200 con un JSON vuoto, e l’applicazione client mostra una pagina bianca.

Cos’è una catena

Una catena ripete la sequenza di chiamate di un vero client. La prima chiamata accede e riceve un token. La successiva usa quel token su una route protetta. Ogni risposta viene verificata prima di passare alla successiva. Se un anello si rompe, la catena si ferma e Lei sa quale.

Come lo fa Chain in Pathly

Una Chain concatena da 1 a 10 chiamate HTTP. Ogni chiamata ha il suo metodo (GET, POST, PUT, PATCH, HEAD o DELETE), le sue intestazioni e il suo corpo. Può aggiungere una pausa tra due chiamate.

• Estrarre un valore dal JSON della risposta, o un cookie, e dargli un nome.
• Riutilizzare quel valore con {{nome}} nell’URL, nelle intestazioni o nel corpo delle chiamate successive.
• Verificare il codice HTTP atteso e la presenza di un testo nella risposta.

Quando una chiamata fallisce, l’avviso indica quale. Lo riceve via e-mail, Slack, Teams, Discord o webhook. Pathly è ospitato nell’Unione europea (europe-west1).

Un esempio concreto: login e poi ordini

La prima chiamata invia un POST su /auth/login e attende un 200. Legge il campo token della risposta e lo conserva con il nome token. La seconda chiama /v1/orders con l’intestazione Authorization: Bearer {{token}}, attende un 200 e verifica che la risposta contenga «orders».

{
  "httpChain": [
    {
      "name": "login",
      "method": "POST",
      "url": "https://api.example.com/auth/login",
      "headers": { "Content-Type": "application/json" },
      "body": "{\"email\":\"[email protected]\",\"password\":\"<test-account-password>\"}",
      "extractJson": { "path": "token", "as": "token" },
      "assertStatus": 200
    },
    {
      "name": "orders",
      "method": "GET",
      "url": "https://api.example.com/v1/orders",
      "headers": { "Authorization": "Bearer {{token}}" },
      "assertStatus": 200,
      "expectText": "orders"
    }
  ]
}

La password del login fa parte della Chain. Usi quindi un account di prova dedicato, con i diritti minimi per leggere la route monitorata, senza dati dei clienti e con una password che non usa da nessun’altra parte. Mai un account reale, e tanto meno un account amministratore.

Un gate CI dopo ogni deploy

La stessa Chain può bloccare una pipeline. L’operazione run-scenario la avvia e fa fallire il job se il risultato non è ok. Esiste nella GitHub Action pathlyhq/pathly-action@v1, pubblicata sul GitHub Marketplace con il nome «Setup Pathly», e nel componente GitLab CI del CI/CD Catalog. Un provider Terraform permette anche di dichiarare la Chain nel Suo codice.

Metta il gate subito dopo il deploy, prima di spostare il traffico o di chiudere il ticket. Un token rotto viene così rilevato dalla pipeline, non da un cliente. Il piano Solo, gratuito e senza carta, include una Chain. I piani a pagamento partono da 29 € al mese.