Posts tagged: xml

RESTEasy: le chiamate rest in Java

In questo piccolo tutorial vedremo come realizzare una piccola chiamata REST verso un servizio remoto, il tutto realizzato in Java. Ricordiamo che le chiamate REST consentono di invocare servizi remoti tramite il protocollo HTTP.
La libreria che ho utilizzato per il supporto alle chiamate REST è RESTEasy la quale oltre al supporto HTTP fornisce il supporto alle annotation JAX-RS. Vediamo subito come procedere. Intanto, utilizzando il vostro IDE preferito (Eclipse ad esempio) create un nuovo progetto e aggiungete le seguente librerie nel build path: 

libraries

Alcune di queste non sono essenziali per la creazione del servizio, ma vi consiglio comunque di lasciarle in modo tale da avere supporto a future implementazioni. Il progetto che sono andato a creare è J2EE installato all’interno di tomcat. Ogni servizio verrà testato da una unit test presente all’interno del progetto stesso, così da verificare la correttezza del servizio. Quindi si parte con la configurazione del nostro web descriptor in modo da configurare il nostro contesto: 

<?xml version="1.0" encoding="UTF-8"?>
 
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
 
    <display-name>resteasy</display-name>
 
    <listener>
        <listener-class>
            org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
        </listener-class>
    </listener>
 
    <servlet>
        <servlet-name>drest</servlet-name>
        <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>drest</servlet-name>
        <url-pattern>/restful-services/*</url-pattern>
    </servlet-mapping>
 
    <context-param>
         <param-name>resteasy.scan</param-name>
        <param-value>true</param-value>    
    </context-param>
 
 
    <context-param>
        <param-name>resteasy.servlet.mapping.prefix</param-name>
        <param-value>/restful-services</param-value>
    </context-param>
 
</web-app>

Fatto questo procediamo con la definizione del servizio. Una premessa fondamentale da fare è la seguente: la creazione di un servizio REST richiede una fase di progettazione attenta e puntuale, in cui molti aspetti devono essere tenuti in considerazione e risolti nel migliore dei modi. L’accesso al servizio, l’autenticazione, l’invio dei dati in input e la restituzione del risultato sono tutti aspetti che fanno parte della progettazione di un servizio. Ciò detto, nel nostro esempio, non considereremo la fase di progettazione in tutti i suoi punti, ma procederemo con la creazione di un servizio a scopo di esempio. Definiamo quindi la classe contenitore del nostro servizio attraverso l’utilizzo delle annotation:

@Path("/devmeservice")
public class DevMeService {
 
	@GET
    @Path("/v1/passes/{pass_type_id}/{device_id}")
    @Produces("text/plain")
    public Response getPassLatestVersion(@HeaderParam("Authorization") String authorization,
					   @PathParam("pass_type_id")String pass_type_id,
					   @PathParam("serial_number")String serial_number){
 
		String auth_token = null;
		if (!authorization.matches("^ApplePass.*")) {
			return Response.status(HttpStatus.SC_FORBIDDEN).build();
		}
		String [] items = authorization.split(" ");
		if (items.length!=2) {
			return Response.status(HttpStatus.SC_FORBIDDEN).build();
		}
 
		auth_token = items[1];
 
		String sql = "SELECT * " +
			 "FROM passes " +
			 "WHERE serial_number = ? AND authentication_token = ? LIMIT 1";
		DBHandle dbhandle = DBHandle.getInstance();
		try {
			PreparedStatement ps = dbhandle.getPreparedStatement(sql);
			ps.setString(1, serial_number);
			ps.setString(2, pass_type_id);
			ResultSet rs = ps.executeQuery();
			if (rs.next()) {
				String pass = readFile(/* PASSES ROOT PATH */"/data/passes/"+serial_number+"/pass.json");
 
			}else {
				return Response.status(HttpStatus.SC_UNAUTHORIZED).build();
			}
		} catch (SQLException e) {
			log.error("Error while registering new device.", e);
			return Response.status(HttpStatus.SC_SERVICE_UNAVAILABLE).build();
		} finally {
			dbhandle.close();
		}
		return null;
    }
 
}

Il metodo di sopra restituisce l’ultima versione di un pass (Passbook) associato ad un particolare dispositivo, sulla base di un codice di autorizzazione concesso al client e dei dati associato al pass stesso. Il metodo verifica prima se il client è autorizzato all’accesso al servizio e successivamente tenta di recuperare le informazioni associate al pass e quindi di restituirlo in output.
Si noti l’utilizzo delle annotation in testa alla classe e in testa al nostro metodo, la prima definizione il nome del servizio che dovrà essere invocato, una sorta di base url. Le seconde annotation definiscono il metodo HTTP che viene utilizzato per l’invocazione del metodo, il percorso del servizio ed infine il mime type della risposta fornita dal metodo. Invocando il servizio con un client HTTP saremo in grado di ottenere la risposta da elaborare localmente.

Nei prossimi articoli tratteremo altri contesti in cui utilizzare le chiamate REST, come i Passbook recentemente introdotti dalla Apple come prossima release in iOS6.

Stay tuned!

SWF: Model Data Validation

spring-webflowDopo aver visto come SWF realizza il mapping tra i dati di un modello e i campi di un form, vediamo ora come creare il meccanismo di validazione che consente di verificare il valore di ciascun campo inserito all’interno di un form. In questo articolo abbiamo visto come viene realizzata il binding dei dati e teniamolo come punto di partenza per iniziare a vedere il meccanismo della validazione.
Riprendiamo il codice sorgente del file di configurazione del flow e la pagina HTML all’interno della quale è presente il form:

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow
        http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
 
    <var name="flight" class="it.devme.flight.Flight" />
 
    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" />
    </view-state>
 
    <view-state id="confirm" view="flight/showFlightInfo" />
 
</flow>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>DevMe - SWF Flight info test - </title>
  </head>
 
<body>
  <h1>Flight information </h1>
  <p>Inserisci le informazioni sul volo:</p>
    <form:form id="flightDetails" modelAttribute="flight">
      <table>
        <tr>
          <td>Numero del volo: </td>
         <td><form:input path="number"/></td>
        </tr>
 
        <tr>
          <td>Ora di partenza: </td>
          <td><form:input path="time"/></td>
        </tr>
 
        <tr>
         <td>Gate: </td>
         <td><form:input path="gate"/></td>
        </tr>
 
        <tr>
          <td>Volo in ritardo: </td>
          <td><form:radiobutton path="isDelayed" value="false" />
  	      <form:radiobutton path="isDelayed" value="true" /></td>
        </tr>
 
        <tr>
          <td><input type="submit" name="_eventId" value="next"></td>
        </tr>
    </table>
    </form:form>
  </body>
</html>

Bene. Come già ampiamente discusso, il flow definito dal file XML di sopra è molto semplice. Abbiamo una sola transizione da uno stato all’altro, ovvero si naviga da una pagina ad un altra pagina. Supponiamo ora, di voler validare i dati del form della pagina di partenza, e spostarsi nella pagina di arrivo, solo se non esistono errori di validazione secondo il nostro personale schema di validazione. Il nostro schema, prevede per semplicità che almeno uno dei tre campi presenti nel form sia indicato, e che se indicato il numero del volo questi dovrà essere un valore numero e eventuali caratteri alfabetici verranno rigettati.

Iniziamo con la modifica del file XML di definizione del flow:

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow
        http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
 
    <var name="flight" class="it.devme.flight.Flight" />
 
    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" >
          <action method="bindAndValidate" bean="flightAction" />
      </transition>
    </view-state>
 
    <view-state id="confirm" view="flight/showFlightInfo" />
 
</flow>

Il metodo bindAndValidate in sostanza richiama la nostra classe validator, la quale effettua i controlli che andremo a definire. Da notare che il riferimento nel tag action, punta ad un metodo all’interno della nostra classe Action che in realtà non esiste, ma che viene ereditato dalla superclasse FormAction. Definendo all’interno del file XML di definizione del bean il riferimento alla nostra classe Validatore, autormaticamente verrà richiamata all’invocazione del metodo bindAndValidate. Il codice della classe che si occupa di effettuare la validazione è il seguente: 

package it.devme.flight;
 
public class FlightValidator implements Validator {
 
	public boolean supports(Class clazz) {
		return clazz.equals(Flight.class);
	}
 
	public void validate(Object target, Errors errors) {
                Flight flight = (Flight) target;
                if (flight.getNumber()==0 && flight.getTime()==null && flight.getGate.equals("")) {
                    errors.rejectValue("gate", "Attenzione, &egrave; necessario specificare almeno 1 tra: numero del volo, ora di partenza, Gate");
                }
 
                if (errors.getErrorCount()==0) {
                    ValidationUtils.rejectIfEmptyOrWhitespace(errors, "gate", "Il campo gate non pu&ograve; essere vuoto.");
                }
	}
 
}

Vediamo cosa è stato fatto. Intanto osserviamo che FlightValidator implementa la classe Validator, quindi definisce alcuni metodi essenziali che sono supports e validate. Il primo assicura il supporto al Bean indicato al suo interno. Il secondo implmenta la logica di validazione. Nel nostro caso vogliamo che almeno uno dei tre campi venga inserito, e che il campo Gate sia diverso da vuoto. Il primo controllo verifica la prima delle nostre condizioni; il secondo if, verifica prima che non ci siano stati errori in precedenza, e in caso positivo effettua il controllo di validazione sul campo Gate.

Vediamo ora come modifichiamo il file HTML per presentare il messaggio di errore:

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>DevMe - SWF Flight info test - </title>
  </head>
 
<body>
  <h1>Flight information </h1>
  <p>Inserisci le informazioni sul volo:</p>
    <form:form id="flightDetails" modelAttribute="flight">
      <table>
        <tr>
          <td>Numero del volo: </td>
         <td><form:input path="number"/></td>
        </tr>
 
        <tr>
          <td>Ora di partenza: </td>
          <td><form:input path="time"/></td>
        </tr>
 
        <tr>
         <td>Gate: </td>
         <td><form:input path="gate"/></td>
         <td><form:errors path="gate"/></td>
        </tr>
 
        <tr>
          <td>Volo in ritardo: </td>
          <td><form:radiobutton path="isDelayed" value="false" />
  	      <form:radiobutton path="isDelayed" value="true" /></td>
        </tr>
 
        <tr>
          <td><input type="submit" name="_eventId" value="next"></td>
        </tr>
    </table>
    </form:form>
  </body>
</html>

Per semplicità il nostro messaggio di errore comparirà sempre nello stesso posto, ovvero sotto il campo Gate. Così nel primo caso di errore, darà contezza del fatto che almeno uno dei campi di precedenti deve essere indicato, mentre nel secondo caso, sarà indicativo del campo stesso. Come vedete, l’aggiunta del tag <form:errors/> fa in modo di collegare eventuali codici di errori con il campo presentato in pagina.

Alla prossima. Stay tuned!

WordPress Themes