Costruttore di richieste API
Perché usare un costruttore di richieste API?
Testare le API REST richiede normalmente di installare Postman, Insomnia o scrivere comandi curl. Il nostro client HTTP basato su browser non richiede installazione — basta aprirlo e iniziare a inviare richieste. Supporta tutti i metodi HTTP, header personalizzati, corpo JSON e parametri di query, rendendolo perfetto per test API rapidi, esplorazione di API pubbliche e debug di integrazioni.
Tutti i metodi HTTP
Supporta GET, POST, PUT, PATCH, DELETE con header personalizzati e corpo JSON/form
Risposta formattata
Il corpo della risposta viene visualizzato automaticamente con rientro, con codice di stato e tempo di risposta
Pronto all'uso
Nessuna installazione richiesta — funziona completamente nel tuo browser senza account o plugin
Come inviare una richiesta API
Inserisci l'URL e il metodo
Digita l'URL dell'endpoint API e seleziona il metodo HTTP (GET, POST, ecc.)
Aggiungi header e corpo
Passa alla scheda Header per aggiungere Authorization, Content-Type e altri. Usa Corpo per i dati POST/PUT.
Invia e ispeziona
Fai clic su Invia per eseguire la richiesta. Il corpo della risposta, il codice di stato e il tempo appaiono in basso.
Casi d'uso del costruttore di richieste API
Debug delle API
Testa endpoint individuali con header e corpi personalizzati per il debug di problemi di autenticazione e dati
Testare i token di autenticazione
Testa schemi Bearer, Basic Auth e chiave API senza scrivere codice
Esplorare le API
Esplora le API pubbliche (GitHub, OpenWeather, JSONPlaceholder) e comprendi le loro risposte
Riprodurre i bug
Riproduci e documenta i bug delle API con i dettagli esatti di richiesta/risposta per i report di bug
Best practice per il test delle API
✓ Imposta sempre Content-Type
Quando invii un corpo JSON, includi sempre Content-Type: application/json. Senza di esso, molte API rifiuteranno o interpreteranno erroneamente la tua richiesta.
✓ Comprendi le limitazioni di CORS
I browser bloccano le richieste cross-origin senza gli header CORS appropriati. Se una richiesta fallisce nel browser, usa curl o un proxy lato server.
✓ Non hardcodare mai le chiavi API
Usa le variabili d'ambiente nel codice di produzione. Il costruttore di richieste è solo per test — non condividere screenshot con chiavi API reali.
✓ Controlla i codici di stato HTTP
200=OK, 201=Creato, 400=Richiesta errata, 401=Non autorizzato, 403=Vietato, 404=Non trovato, 500=Errore del server.
❓ Domande frequenti
Perché la mia richiesta cross-origin fallisce?
I browser applicano le restrizioni CORS (Cross-Origin Resource Sharing). Se l'API di destinazione non include header Access-Control-Allow-Origin, il browser blocca la richiesta. Non è un bug — usa curl o un proxy backend per le API senza supporto CORS.
Posso inviare richieste multipart/form-data?
L'attuale costruttore supporta corpi JSON e testo semplice. Per i dati form multipart (caricamento di file), usa l'invio di form nativo del browser o uno strumento dedicato come Postman.
È un sostituto di Postman?
Per test rapidi ed esplorazione — sì. Per la collaborazione in team, le raccolte salvate, gli ambienti e i test automatizzati, Postman o Bruno offrono più funzionalità. Questo strumento eccelle nei test API istantanei senza configurazione.
Qual è la differenza tra PUT e PATCH?
PUT sostituisce l'intera risorsa con il corpo della richiesta. PATCH applica un aggiornamento parziale — solo i campi inclusi nel corpo vengono modificati. La maggior parte delle API REST usa PATCH per gli aggiornamenti per non sovrascrivere i campi non modificati.