Controllore di Endpoint API

La richiesta va direttamente dal browser all'endpoint, senza passare dal nostro server. Si applica CORS e i cookie vengono omessi. Nella modalità a passaggi, i dati restano temporaneamente in questa scheda fino al caricamento del passaggio 2, quindi vengono rimossi dall'archivio di sessione. L'endpoint riceve comunque URL, intestazioni, corpo e indirizzo IP.

Incolla un URL HTTP o HTTPS: lo strumento invia una richiesta GET, HEAD, POST, PUT, PATCH o DELETE direttamente dal browser. Mostra lo stato finale, il tempo fino alle intestazioni, le intestazioni esposte da CORS, l’URL finale dopo un reindirizzamento e fino a 1 MiB del corpo. L’endpoint deve consentire l’origine del browser tramite CORS perché la risposta sia leggibile.

Come controllare un endpoint API

  1. 1

    Inserisci l'URL

    Includi lo schema (http:// o https://). Lo strumento segue i reindirizzamenti per impostazione predefinita.

  2. 2

    Scegli il metodo HTTP

    GET è il predefinito. Passa a HEAD per un controllo più leggero, POST/PUT/PATCH con un corpo per testare endpoint di scrittura.

  3. 3

    Aggiungi intestazioni se necessario

    Le intestazioni di autorizzazione, Accept, Content-Type e intestazioni personalizzate possono essere impostate. Utile per testare l'autenticazione con chiave API o la negoziazione del contenuto.

  4. 4

    Controlla il risultato visibile nel browser

    Controlla stato finale, tempo, intestazioni esposte da CORS, URL finale dopo un reindirizzamento e un'anteprima del corpo limitata a 1 MiB.

Riferimento codice di stato HTTP

Codice Significato Azione
200 OK Successo
201 Creato POST/PUT ha prodotto una risorsa
204 Nessun contenuto Successo senza corpo
301 Spostato Permanentemente Segui il reindirizzamento, aggiorna i link
302 Trovato (reindirizzamento temporaneo) Segui il reindirizzamento
304 Non Modificato Copia cache ancora valida
400 Richiesta Errata Correggi la richiesta
401 Non Autorizzato Credenziali mancanti o non valide
403 Vietato Autenticato ma non autorizzato
404 Non Trovato URL errato o risorsa non disponibile
429 Troppe Richieste Fai una pausa, rispetta il limite di frequenza
500 Errore Interno del Server Bug del server
502 Bad Gateway Il server upstream è inattivo
503 Servizio Non Disponibile Manutenzione o sovraccarico
504 Timeout del Gateway Il server upstream non ha risposto in tempo

Riferimenti ai tempi di risposta

Tempo di risposta Percezione
Sotto 100 ms Istantaneo
100-300 ms Veloce
300-1000 ms Accettabile
1-3 secondi Lento, gli utenti notano
Oltre 3 secondi Da indagare per usi interattivi

Queste fasce sono riferimenti diagnostici, non limiti universali. Se l’API ha uno SLA, confronta più campioni con gli obiettivi p95 e p99 dichiarati.

Intestazioni comuni da controllare

  • Content-Type, application/json; charset=utf-8 vs. text/html ti dice cosa stai effettivamente ricevendo.
  • Cache-Control, max-age=3600, public vs. no-store determina se le cache CDN e del browser verranno utilizzate.
  • Access-Control-Allow-Origin, per il debug CORS. Deve essere * o esplicitamente l’origine richiesta.
  • Strict-Transport-Security, La presenza di HSTS conferma l’applicazione esclusiva di HTTPS.
  • X-RateLimit-Remaining, molte API pubblicano la quota rimanente per risposta.

Cosa non può mostrare una richiesta dal browser

  • Fetch segue i reindirizzamenti consentiti e mostra l’URL finale, ma non l’intera catena.
  • Il browser convalida HTTPS, ma JavaScript non può leggere emittente, scadenza o catena del certificato.
  • CORS decide se la pagina può leggere stato, corpo e la maggior parte delle intestazioni. Un errore CORS non dimostra che l’API non sia disponibile.
  • Il browser controlla Host, Origin, Cookie, Content-Length e User-Agent; lo strumento li rifiuta invece di fingere di inviarli.

Domande frequenti

Fetch segue i reindirizzamenti e rende disponibili risposta e URL finali, non ogni passaggio. Lo strumento omette inoltre i cookie del browser; un’API può cambiare risposta in base a cookie, origine o altre intestazioni controllate dal browser.

Sì, se l’endpoint consente la richiesta CORS risultante. I valori Authorization vengono inviati direttamente a quell’endpoint. Nella modalità a passaggi, i campi restano temporaneamente nella scheda fino al caricamento del passaggio 2 e poi vengono eliminati dall’archivio di sessione; non passano dal nostro server. Non usare segreti di produzione con endpoint non attendibili.

Il timer gira nel browser da appena prima di Fetch fino all’arrivo delle intestazioni di risposta. Include il costo del browser e della rete, mentre i log server spesso misurano solo l’elaborazione applicativa. Non comprende il download del corpo; confronta più prove dallo stesso browser e dalla stessa rete.

No. Questo controllo usa Fetch del browser per normali richieste HTTP e HTTPS. WebSocket e gRPC richiedono client specifici e non vengono testati qui.

Strumenti correlati