Client / Tester API REST

Componga e invii richieste HTTP con parametri di query, intestazioni, corpi JSON / form e autenticazione Basic o Bearer, poi ispezioni stato, tempi e risposte JSON formattate. Importi un comando cURL esistente oppure copi la richiesta corrente come cURL. Preferisce costruire richieste riutilizzabili passo dopo passo? Usi il Costruttore di richieste HTTP. Veda anche la famiglia Strumenti API.
Tutto funziona localmente nel suo browser. Le richieste cross-origin sono soggette alla politica CORS del server di destinazione — veda la nota sotto se una richiesta fallisce.
Parametri di query
Intestazioni
Corpo
Autorizzazione
Opzioni
Se compilato, l'URL della richiesta viene aggiunto a questo prefisso. Utile per i server bloccati da CORS.
200
Corpo Intestazioni

                                                                
Perché una richiesta può fallire: i browser bloccano le letture cross-origin a meno che l'API non restituisca Access-Control-Allow-Origin. Se la destinazione non consente CORS, può eseguire un proxy CORS proprio e incollarne l'URL nel prefisso proxy sopra, oppure usare il Convertitore cURL per eseguire la richiesta da terminale. I corpi delle richieste GET/HEAD vengono ignorati, e uno strumento WebSocket è separato nel Tester WebSocket.
Metodi HTTP spiegati
Il metodo che sceglie indica al server cosa desidera fare con l'URL. Ecco il significato di ciascuno dei sette verbi che questo strumento può inviare:
GET — Recupera una risorsa: una pagina web, un'immagine, un elenco di record. «Mi dia ciò che si trova a questo URL.» È di sola lettura e sicuro da ripetere, e di solito non porta un corpo di richiesta (un corpo in una richiesta GET, se presente, viene ignorato).
POST — Invia dati nuovi al server, di solito per creare una risorsa o avviare un'azione — inviare un modulo, caricare un file, avviare un processo. Il carico utile viaggia nel corpo della richiesta. POST non è idempotente: inviare due volte lo stesso POST può creare due record.
PUT — Sostituisce l'intera risorsa all'URL con ciò che invia. Il corpo deve contenere la versione completa della nuova risorsa. PUT è idempotente: ripetere la stessa richiesta ha lo stesso effetto che inviarla una volta sola.
PATCH — Cambia solo una parte di una risorsa. Invia soltanto i campi da aggiornare, es. {"email": "new@example.com"}, invece dell'intero record. Scelga PATCH quando un PUT completo la obbligherebbe a rinviare campi che non sta modificando.
DELETE — Rimuove la risorsa all'URL. DELETE è idempotente: eliminare qualcosa già scomparso restituisce lo stesso esito (di solito un 404) e non fa nulla due volte.
HEAD — Come GET, ma la risposta contiene solo intestazioni — nessun corpo viene restituito. Usi HEAD per verificare se un URL esiste, quanto è grande un file (Content-Length), quando è stato modificato l'ultima volta (Last-Modified) o di che tipo è (Content-Type), senza scaricare l'intero contenuto.
OPTIONS — Chiede al server quali metodi e opzioni sono consentiti per un URL, oppure attiva una verifica preliminare CORS. Le intestazioni di risposta, come Access-Control-Allow-Methods, elencano ciò che è permesso. OPTIONS di solito non porta un corpo; i browser spesso lo inviano automaticamente prima di un POST/PUT/PATCH/DELETE cross-origin.
Facili da confondere: HEAD contro GET — la richiesta è identica, ma HEAD non restituisce corpo. PUT contro PATCH — PUT sostituisce l'intera risorsa; PATCH applica un aggiornamento parziale dei soli campi che invia.