Strumento di prova per API REST

Uno strumento che permette di inviare richieste HTTP a un'API REST direttamente dal browser e di esaminarne la risposta. In alternativa a Postman o a cURL, semplifica lo sviluppo e la verifica delle API.

{{ alert.msg }}
Richiesta
URL
Metodo
Dati
Intestazioni {{ hkey }} {{ hval }}
Intestazioni

Risposta
Stato {{ status }}
Intestazioni

{{ hkey }}: {{ hval }}

Se l'API non restituisce l'intestazione «Access-Control-Allow-Origin» con il valore «*», non è possibile ottenere i dati. Con Google Chrome potete valutare l'uso di un'estensione dedicata.

https://chromewebstore.google.com/detail/cors-unblock/lfhmikememgdcahcdlaciloancbhjino

Consigli per l'uso

  • Per le restrizioni sulla condivisione delle risorse fra origini diverse non si possono interrogare direttamente le API prive dell'intestazione Access-Control-Allow-Origin: usate lo strumento con API pubbliche o già abilitate.
  • Indicando nell'intestazione della richiesta Content-Type: application/json potete inviare un corpo in formato JSON.
  • Codici di stato HTTP: 2xx successo, 4xx errore del client (401 per l'autenticazione, 404 per la risorsa non trovata), 5xx errore del server.
  • Per le API che richiedono l'autenticazione con token, aggiungete l'intestazione Authorization: Bearer {token}.

Domande frequenti

Poiché lo strumento invia la richiesta direttamente dal browser, se l'API non restituisce l'intestazione Access-Control-Allow-Origin si genera quell'errore. Potete usare un'estensione del browser che aggira la restrizione oppure provare con un'API che consente le richieste fra origini diverse.

Aggiungete nell'intestazione della richiesta Content-Type: application/json, scrivete la stringa JSON nel campo del corpo e inviate.

Aggiungete nell'intestazione della richiesta Authorization: Bearer {vostro_token}, sostituendo la parte fra parentesi con la stringa reale del token.
Tool-kun

A proposito — la nascita di REST: la tesi di dottorato che cambiò lo sviluppo web

REST è lo stile architetturale proposto nel 2000 da Roy Fielding nella sua tesi di dottorato «Architectural Styles and the Design of Network-based Software Architectures». Fielding è anche uno dei principali coautori della specifica HTTP/1.1 e concepì REST proprio mentre sistemava i principi progettuali del protocollo.

Intorno al 2010 Twitter passò dall'approccio SOAP a un'API REST e, aprendola agli sviluppatori, ne favorì la diffusione esplosiva. Oggi moltissimi servizi noti — dai pagamenti allo sviluppo collaborativo, dalla messaggistica ai servizi di intelligenza artificiale — pubblicano API REST e alimentano quel mercato che si è preso a chiamare economia delle API.

Nella progettazione delle API REST rientra, nella formulazione originaria, il vincolo dell'ipermedia come motore dello stato dell'applicazione, ma sono pochissimi i servizi che lo attuano rigorosamente. La discussione su che cosa sia «vero REST» torna periodicamente ad accendersi nella comunità degli sviluppatori e la definizione stessa dell'aggettivo resta oggetto di dibattito.