Una volta creato un Web service occorre metterlo alla prova e verificare se si comporta come ci aspettiamo. I motivi di eventuali malfunzionamenti potrebbero essere diversi e di diversa natura. Per comprenderne la causa è essenziale intercettare le richieste e le risposte scambiate tra client e Web Service.
Per testare l'esecuzione del metodo GET su una risorsa sarebbe sufficiente un comune Web browser, ma già per l'esecuzione del metodo POST la cosa si fa un pò più complessa. Per gestire i metodi PUT e DELETE dovremmo creare un client ad hoc.
Possiamo evitare di crearci un client utilizzando uno dei numerosi strumenti per l'esecuzione di richieste HTTP disponibili in rete, che si differenziano più che per le funzionalità di base per la capacità di integrarsi in un ambiente piuttosto che in un altro.
Poster è, ad esempio, un add-on di Firefox molto comodo da usare e con una interfaccia grafica semplice ma abbastanza completa. Come tutti gli strumenti di questo tipo, oltre alla possibilità di richiedere una risorsa con i vari metodi HTTP, è possibile specificare le intestazioni, i parametri, il contenuto del corpo della richiesta e le credenziali di autenticazione.
Anche RESTClient è un add-on di Firefox con
funzionalità analoghe a Poster. Tuttavia con lo stesso nome esistono anche altri strumenti per il test ed il debugging di connessioni HTTP. Ad esempio così si chiamano un client Java con versione a riga di comando e versione con interfaccia grafica ed una piccola applicazione scritta in Python.
Fiddler è uno strumento un pò più complesso che fa molto più che da semplice client RESTful. Esso è un vero e proprio debugger HTTP con la possibilità di tenere traccia di tutte le connessioni HTTP in uscita da una macchina.
Infine HTTP4e è un plugin per Eclipse che
aggiunge alla funzionalità standard di creazione ed invio di richieste HTTP, alcune caratteristiche tipiche di un ambiente di sviluppo, come ad esempio i suggerimenti automatici quando si digitano parole chiave nelle intestazioni, visualizzazioni diverse del corpo della risposta HTTP e la possibilità di generare il codice di un client RESTful in Java, PHP, C# e in altri linguaggi
di programmazione.
Ma al di là dello specifico strumento utilizzato, cosa dobbiamo analizzare per capire qual è la causa di un malfunzionamento?
Ecco una breve checklist di punti da tenere presente analizzando le richieste e le risposte scambiate da client e server:
- Il client riesce ad inviare la richiesta?
Sembra un'osservazione banale, ma può verificarsi che il client non sia in grado di comunicare con il Web service; può essere il caso di un URL scritto male o una
regola del firewall che impedisce la comunicazione. - La richiesta inviata dal client è conforme alle specifiche del Web Service?
Occorre verificare la richiesta HTTP sia correttamente formulata, analizzando sia l'eventuale contenuto del corpo che le intestazioni HTTP. - Il client riesce a ricevere la risposta dal Web Service?
Come per il caso di invio della richiesta, anche per la ricezione potrebbero verificarsi problemi legati al firewall, a meno che la mancata risposta non dipenda da un problema specifico del Web Service. - La risposta ricevuta dal client è conforme alle specifiche?
L'analisi della risposta e della sua conformità alle specifiche previste può essere fondamentale per l'individuazione del malfunzionamento; da non trascurare le intestazioni HTTP.