REST
Un Survol des principaux concepts
(basé essentiellement sur le support SUN par [Link])
1
REST?
• REST (REpresentational State Transfer) est un style
d’architecture pour les systèmes hypermédia distribués
• Créé par Roy Fielding en 2000 (thèse de doctorat)
• REST n’est pas un protocole (tel que HTTP) ou un format
• Style d'architecture particulièrement bien adapté au WWW mais
n'est pas dépendant du Web.
– Peut s'appliquer à d'autres protocoles d'application que HTTP.
2
REpresentational State Transfer (REST)
• L’URL c’est la Ressource
• GET pour afficher la page à partir du serveur
– Transfert de l’état de la ressource sur le navigateur du client
• Les ressources sont accessibles à travers des liens hyperlink
3
Concepts clés
• Ressources (noms)
– Identifiées par une URI, Exemple: [Link]
• Méthodes (verbes) afin de manipuler les ressources
– Create, Read, Update, Delete
• Représentation est la manière de voir/échanger l’état de la
ressource
– Transfert de données et d’état entre le serveur et le client
– XML, HTML, JSON...
4
Exemple
5
REST en 5 étapes
• Donner un ID pour chaque ressource
• Utiliser les méthodes standard d’HTTP
• Lier les ressources entre elles
• Choix entre multiples représentations
• Communication sans état (Stateless)
6
Etape 1: Donner un ID pour chaque ressource
• [Link]
– Le client num 1234 de la collection de clients
• [Link]
• [Link]
– La commande num 12 du client num 1234
7
Etape 2: Utiliser les méthodes standards d’HTTP
• GET: Lecture d’une information (ressource)
– éventuellement déjà présente dans le cache
– Sans effet de bord
• Exp. GET /toto/customers/1234
• POST: Créer une nouvelle information (ressource) sans l’ID
– Créer la ressource et la rajouter à une collection
– Exp. POST /toto/customers
• Ajoute le client spécifié dans le POSTDATA à la collection des clients.
• L’opération retourne l’URI de la nouvelle ressource créée
8
Etape 2: Utiliser les méthodes standards d’HTTP
• PUT: Mise à jour /création d’une ressource avec un ID
connu
– Exp. PUT /toto/customers/1234
• Remplace le client num 1234 avec une nouvelle version
• DELETE: Effacer une ressource
– Exp. /toto/customers/1234
• Efface le client num 1234 du système
9
Ce qui change dans la conception
10
Etape 3: Lier les ressources entre elles
• Permet au client de faire évoluer l’application d’un état à un autre
en suivant des liens et en remplissant des formulaires
<order self=’[Link]
<amount>23</amount>
<product ref=’[Link] />
<customer ref=’[Link] />
</order>
11
Etape 4: Choix entre multiples représentations
• Plusieurs formats possibles selon les besoins
– XML, JSON, (x)HTML
// This method is called if TEXT_PLAIN is request
@GET
@Produces(MediaType.TEXT_PLAIN)
public String sayPlainTextHello() {
return "Hello Jersey";
}
// This method is called if XML is request
@GET
@Produces(MediaType.TEXT_XML)
public String sayXMLHello() {
return "<?xml version=\"1.0\"?>" + "<hello> Hello Jersey" + "</hello>";
}
// This method is called if HTML is request
@GET
@Produces(MediaType.TEXT_HTML)
public String sayHtmlHello() {
return "<html> " + "<title>" + "Hello Jersey" + "</title>" + "<body><h1>" +
"Hello Jersey" + "</body></h1>" + "</html> ";
}
12
Etape 5: Communication sans état (Stateless)
• HTTP est Stateless (sans état)
• Tout ce qui est nécessaire pour traiter une demande est
dans l’objet Request
• Le client est responsable de l’état de l’application
• Le serveur est responsable de l’état de la ressource
• Exp. Agence de voyage en ligne
– Créer un voyage, définir l’itinéraire, le soumettre, etc.
– Le tout est géré coté client et non pas sur la session du serveur
13
Etape 5: Communication sans état (Stateless)
14
REST: Principaux avantages
• Coté Serveur
– Plus de passage à l’échelle (scalable)
– Reprise après panne
– Utilisation optimisée du cache
– Couplage réduit
– Fonctionne avec les infrastructures actuelles
– Interface uniforme
• Coté Client
– Lien bookmarkable (favoris)
– Besoin d’un simple navigateur
– Plusieurs langages supportés
– Plusieurs choix de formats de données
15
REST
Un exemple
- Utilisation d’annotations JAX-RS
16
Etape 1: Donner un ID pour chaque ressource
• Une ressource => Classe POJO (Plain Old Java Object)
– Pas d’interface requise!
• L’ID est défini par l’annotation @Path
– Relative au contexte de déploiement
– Peut être utilisée pour annoter la classe ou directement la
méthode censée retourner la ressource
17
Etape 1: Donner un ID pour chaque ressource
• Comment mapper les URIs aux Classes:
18
Etape 1: Donner un ID pour chaque ressource
• Deux manières de créer des sous-ressources
public class ItemResource {
@Path("/items/{id}/")
@GET
public ItemConveter get(@PathParam("id") Long id) {
.....
}
@Path("/items/")
public class ItemsResource {
@Path("{id}/")
public ItemResource getItemResource(@PathParam("id") Long id) { ...
return resource;
}
19
Etape 2: Utiliser les méthodes standards d’HTTP
• Annoter les classes de ressources avec les méthodes
standards selon le besoin
– @GET, @PUT, @POST, @DELETE
Le @Path n’est pas donné
dans l’exemple, il est défini
avant la signature de la
classe
20
Etape 2: Utiliser les méthodes standards d’HTTP
• Possibilité d’extraire les informations à partir des
paramètres de la requête avec @QueryParam
21
Etape 3: Lier les ressources entre elles
• UriInfo donne l’information sur le contexte de déploiement,
l’URI, et le chemin jusqu’à la ressource
• UriBuilder offre des facilités pour créer les URIs des
ressources
22
Etape 4: Choix entre multiples représentations
• Annoter les méthodes ou bien les classes avec
– @ProduceMime, @ConsumeMime
23
Etape 4: Choix entre multiples représentations
24
Etape 4: Choix entre multiples représentations
• JAX-RS peu automatiquement faire du Marshalling/
UnMarshaling entre les messages HTTP et les types Java.
Support de:
• text/xml, application/xml, application/json – JAXB class
• */* – byte[], InputStream, File, DataSource
• text/* – String
• application/x-www-form-urlencoded -MultivaluedMap<String, String>
• Il suffit d’annoter
votre pojo avec
@XmlRootElement
25
Etape 4: Choix entre multiples représentations
• Exemple complet
La classe de service La classe utilisée par JAXB
annontée par JAX-RS pour créer la représentation
JSON ou XML
package [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
@Path("/todo")
public class TodoResource {
// This method is called if XMLis request
@GET @Produces({ MediaType.APPLICATION_XML,
MediaType.APPLICATION_JSON })
public Todo getXML() {
Todo todo = new Todo();
[Link]("This is my first todo");
[Link]("This is my first todo");
return todo; }
// This can be used to test the integration with the browser
@GET @Produces({ MediaType.TEXT_XML })
public Todo getHTML() {
Todo todo = new Todo();
[Link]("This is my first todo");
[Link]("This is my first todo");
return todo; }
}
26
Etape 5: Communication sans état (Stateless)
• Une nouvelle instance est créée pour chaque requête
– Réduit les problèmes de concurences
• Les sessions HTTP ne sont pas supportées
• Le développeur doit gérer l’état de l’application à
travers les représentations
27
Et le WSDL dans tout ça?
• Pas nécessaire mais un format existe, WADL!!
– WADL (Web Application Description Language)
– [Link]
28
Conclusion
• Style architectural de plus en plus utilisé
• Défini comme étant le vrai WEB contrairement aux WS
SOAP
• Jeunesse encore au niveau des standards de sécurité,
transactions, etc.
• Eviter de généraliser!! Le tout Rest ou le tout SOAP!!
29
