Architecture REST & Web Services Exposé – Informatique & Réseaux CHAMBON Florian 14 janvier 2014

Introduction Présentation de Rest Serveur Java JAX-RS Démonstration C’est quoi ? A quoi cela correspond ? Exposé - Informatique & Réseaux

Introduction Présentation de Rest Serveur Java JAX-RS Démonstration C’est quoi ? A quoi cela correspond ? Exposé - Informatique & Réseaux

Web Services Un service est un travail réalisé par un fournisseur pour le compte d’un consommateur Un service web est un programme informatique permettant la communication et l’échange de données entre applications et systèmes hétérogènes dans des environnements distribués – Wikipédia Ensemble de fonctionnalités métier exposées sur internet/intranet par et pour des application / machines – Communication inter application Programme informatique (web) qui permet la communication / échange de données entre applications / systèmes hétérogènes dans des environnement distribués. L’avantage d’un web service réside dans ll’inperrabilité des systemes Une application java / Windows peut communiquer avec une application .Net / Linux Service / Fonctionnalité utilisable au travers du réseau en mettant en œuvre un format standard Agent = Veut un service Fournisseur de service = Il fournit le service 1 - Un client appelle les services web 2 - Le serveur traite la demande et renvoie le résultat au client 3 - Le client utilise le résultat Plusieurs utilisateurs possibles : Humain Application Permet de mettre a disposition une fonctionnalité métier à travers le réseau. Exposé - Informatique & Réseaux

Web services - Technologies Un peu d’histoire DCE / RCP - Distribued Computing Environnement CORBA – Common Object Request Broker Architecture DCOM – Distribued Component Object Model RMI – Monde Java Plusieurs technologies permettent d’implementer les Web Services XML-RPC SOAP services Representational State Transfer (REST) XML-RPC : Protocole RPC ( Remote procedure call ) Permet d’appeler une fonction sur un serveur distant à travers un réseau. Protocole créé en 1998 (Microsoft) Fonctionne avec XML. Protocole réseau SOAP : Simple Object Access Protocol Permet a un objet d’invoquer des méthodes physiquement situées sur un autre serveur => Transfert HTTP Normalisé par le W3C. REST VS SOAP Rest : Leger Rest : Resultat exploitable par humain ( Lol ? ) Rest : Architecture plus simple Exposé - Informatique & Réseaux

Introduction Présentation de Rest Serveur Java JAX-RS Démonstration C’est quoi ? A quoi cela correspond ? Exposé - Informatique & Réseaux

Representationnal State Transfer Créé pour interagir avec les systèmes distribués Architecture orienté ressources Créé en 2000 par Roy Fielding - Thèse de doctorat Projet Waka Principal auteur de la spécification HTTP Membre fondateur de la fondation Apache Développeur du serveur Web Apache Exposé - Informatique & Réseaux

Representationnal State Transfer REST n’est pas : Un standard Un protocole Un format REST est : Bonne pratique Pas de spécifications de la W3C Une approche pour construire une application Un type d’architecture pour les systèmes distribués Exposé - Informatique & Réseaux

Representationnal State Transfer Web services = interopérabilité Indépendant de la plateforme Indépendant du language Utilise le Protocole HTTP pour échanger l’échange de données Exposé - Informatique & Réseaux

Contraintes Contraintes émises par Roy Fielding Client / Serveur - HTTP Stateless – Sans état Cache Architecture multi couches On peut résumer le style d‘architecture REST à un ensemble de contraintes à satisfaire, au nombre de 6 : Dans la these de Roy Fieldling [Client Server] Architecture client serveur Une interface uniforme sépare clients de serveurs. Cette séparation des préoccupations signifie que 1 - Les clients ne sont pas concernés par l’implémentation du stockage de données , qui reste interne à chaque serveur = Portabilité 2 - Serveurs ne sont pas concernés par l'état de l'interface utilisateur ou utilisateur. Des serveurs et des clients peuvent également être remplacés et mis au point de manière indépendante , dans la mesure où l'interface entre eux ne soit pas modifié Permet de faire évoluer le client ou le serveur de façon indépendante La séparation des responsabilités entre le client et le serveur offre un découplage favorable à l’évolution du système dans son ensemble. Ce type d’architecture n’est pas propre au style REST, ce dernier s’en inspire tout simplement. [Stateless] Sans état (coté serveur) Chaque requête doit porter suffisamment d’information pour être comprise par le serveur sans que celui-ci n’ait besoin de retrouver le fruit des interactions précédentes avec ce client en particulier. Cela permet d’assurer une meilleure capacité à monter en charge, mais aussi d’améliorer la robustesse (la perte d’une session est toujours un problème, et sa réplication encore plus…) La communication client - serveur est en outre limitée par aucun contexte du client étant stocké sur le serveur entre les requêtes. Chaque demande de tout client contient toutes les informations nécessaires pour traiter la demande , et l'état de session est maintenu dans le client . Il importe de noter que l'état de session peut être transféré par le serveur à un autre service comme une base de données pour maintenir un état persistant pour une période et permettre l'authentification . Le client commence à envoyer des demandes quand il est prêt à faire la transition vers un nouvel état . Alors une ou plusieurs demandes sont en circulation, le client est considéré comme étant en transition . La représentation de chaque état ​​de l'application contient des liens qui peuvent être utilisés la prochaine fois que le client décide d'engager un nouvel état - transition [Cache] Utilisation du cache On parle d’architecture distribuée et donc d’échanges réseau. La contrainte du cache est naturellement là pour optimiser les performances. Cette contrainte induit que les réponses du service indiquent au client si elles peuvent être mises en cache ou non, lui laissant la possibilité de ne pas requêter à nouveau si la ressource est présumée encore “ fraîche” Comme sur le World Wide Web , les clients peuvent mettre en cache les réponses . Les réponses doivent donc , implicitement ou explicitement , se définir comme être mis en cache , ou non , pour empêcher les clients de réutiliser les données obsolètes ou inappropriées en réponse à de nouvelles demandes . La mise en cache bien géré partiellement ou élimine complètement certaines interactions client-serveur , améliorant encore l'évolutivité et les performances [Uniform Interface] Interface uniforme Cette contrainte augmente encore le découplage entre le client et les ressources en rendant générique la façon d’interagir avec les ressources. Le style REST spécifie sous forme de nouvelles contraintes ce qu’est une interface uniforme. Ces contraintes d’interface sont : Une identification des ressources. Cela permet de faire référence à des ressources de façon non équivoque et de créer des liens pérennes entre ressources. L’utilisation de Représentations pour interagir avec les Ressources. Une ressource peut avoir une ou plusieurs représentations, que le client manipulera et dont il se servira pour communiquer avec le service, lequel agira sur la ressource en conséquence. Messages auto descriptifs. Une réponse à une requête portera par exemple une information sur le type de représentation retourné, permettant au client de savoir comment la traiter. Gestion des transitions par liens hypermédia. Les possibilités d’interactions avec une ressource au travers ses représentations sont décrites dans les messages par des liens hypermédia, permettant au client de “découvrir” ce qui lui est permis de faire. [Layered System] Architecture multi-couches On parle ici des couches d’une architecture complète. Considérant le cas d’un service REST reposant sur HTTP, ces couches sont par exemple un reverse proxy, un service d’authentification, … Le client ne doit pas avoir besoin de connaître, ni quelle est la première couche avec laquelle il communique, ni combien de couches le séparent des ressources manipulées. D’ailleurs la configuration des couches doit pouvoir évoluer sans impact sur le client. Ici, l’interface unifiée est un des éléments permettant cette souplesse. Proxy Load Balancer Service Authentification [Code-on-demand] Code à la demande Optionnel Offre la possibilité de fournir au client par le biais, de scripts fournis par le serveur qu’il pourra exécuter, l’accès à des fonctionnalités sans besoin au préalable qu’il les ait implémentées. Cette contrainte est notée comme optionnelle. Elle doit rester optionnelle aussi dans le sens ne pas bloquer l’utilisation du service si le client ne permet pas l’exécution du code en question (“non obtrusive”). Elle peut avoir du sens par exemple dans un environnement maîtrisé (typiquement en entreprise). Exposé - Informatique & Réseaux

Architecture Exposé - Informatique & Réseaux

Rest - Principe clés Une ressource distribuée sur un serveur distant Un identifiant de la ressource Des « verbes » HTTP permettant d’agir sur la ressource Une représentation de la ressource Dans une architecture Rest : L’information est une resource désgnée par une URL. Les ressources sont manipulées par des Opérations simples. Un Client / serveur rest utilise le protocole sans état HTTP. Exposé - Informatique & Réseaux

Une ressource distribuée Idéalement, chaque URL aurait une version lisible par un humain et une représentation pour une machine. Quand la machine prend une ressource, elle demandera la version appropriée lisible par la machine. Quand un navigateur prend la ressource pour un humain, il demandera celle lisible par un humain. Exposé - Informatique & Réseaux

URL : Identifiant de la ressource Uniforme Ressource Locator Deux types d’URL : URL member qui désigne une seule ressource ( Livre ) URL collection qui désigne une liste de ressources de même type http://address:port/RootContext/Ressource(s) En cliquant sur l'URI suivante, vous obtenez la météo de Paris. Le fait de cliquer sur le lien indique au navigateur que vous voulez obtenir une représentation de la ressource désignée. Le navigateur reconnaît http comme protocole et envoie alors au serveur fr.weather.com une requête HTTP GET sur le port 80. En retour, le serveur lui envoie la représentation actuelle de la ressource /weather/local/FRXX0076. Cette représentation comporte deux parties, des métadonnées qui décrivent le contenu de la représentation Cette notion d'URI est fondamentale car c'est le système global et unique d'identification du Web. L'URI est la pierre angulaire de l'architecture Web. Elle permet d'accéder en un "simple clic" à une multitude de protocoles et de représentations. La portée globale des URI entraîne un effet réseau global. Plus un identifiant est utilisé, plus sa valeur augmente. Le système d'URI a été largement déployé depuis les débuts du Web et les avantages des URI sont nombreux : liens, favoris, mécanismes de cache, indexation par les moteurs de recherches. En utilisant les URI, il est possible de déployer une application partout dans le monde sans infrastructure additionnelle comme des annuaires ou des "registries". Déployer un autre système de nommage qui aurait les mêmes propriétés que les URI serait très coûteux. Exposé - Informatique & Réseaux

HTTP – Identifiant des opérations GET Usage : Read – Lecture d’une ressource / d’une collection 200 OK – 404 NOT FOUND PUT Usage : Update – Mise à jour d’une ressource 201 CREATED – 204 NO CONTENT DELETE Usage : Delete – Supression d’une ressource 200 OK – 404 NOT FOUND – 304 NOT MODIFIED POST Usage – Create – Création d’une ressource GET pour récuperer la ressource POST : pour ajouter une ressource PUT : Pour modifier une ressrouce identifiée par une URI. DELETE : pour supprimer une ressource PUT and DELETE can be blocked by firewalls La donnée peut être sollicité par des opération HTTP. Exposé - Informatique & Réseaux

Exemple - Library URL Méthode Action http://locahost:8080/Library GET Récupération de tous les livres de la bibliothèque. http://localhost:8080/Library/isbn-12 Récupération dans la bibliothèque d’un livre avec id = 12 http://localhost:8080/Library/ POST Création d’un livre dans la bibliothèque : Paramètres passées dans le corps de la requête HTTP http://localhost:8080/Library/15-HarryPotter-JKRowling-Fantasy Création d’un livre dans la bibliothèque avec les paramètres passée via l’URL http://locahost:8080/Library/isbn-12 PUT Modifie le livre d’ID 12 avec les paramètres passés dans le corps de la requête DELETE Supprime le livre d’ID 12 de la bibliothèque Exposé - Informatique & Réseaux

Réponses HTTP – Représentation des ressources Le serveur ne renvoie pas une ressource mais une représentation de la ressource. Pas de format d’échange imposé Entête HTTP contient le type de la représentation : Content Type Une ressource : Plusieurs représentations possibles HTML CVS XML JSON Exposé - Informatique & Réseaux

JSON et XML { Isbn : 2070541274, author : JK rowling, title : Harry potter n° X, style : Fantasy } <Book> <Isbn>2070541274</isbn> <author>JK Rowling</author> <title> Harry Potter .. </title> <style> Fantasy </style> </Book> Exposé - Informatique & Réseaux

Qui l’utilise ? Exposé - Informatique & Réseaux

Avantages de REST Facile à comprendre et à implémenter ( Framework dans plusieurs langages : Java – Python - Php ) Un client HTTP suffit pour accéder à un service RESTful. Interopérabilité des systèmes Interopérabilité des langages Architecture scalable : Possibilité de répartir les requêtes sur plusieurs serveurs – stateless. L'utilisation de formats standards comme JSON ou XML assure la compatibilité dans le temps. La thèse de Roy Fielding précise les avantages de ce style architectural par rapport à d’autres styles d’architectures d’applications Web. Citons entre autres : L’application est plus simple à entretenir, car elle désolidarise la partie client de la partie serveur. La nature hypermédia de l'application permet d'accéder aux états suivants de l'application par inspection de la ressource courante. L'absence de gestion d’état du client sur le serveur conduit à une plus grande indépendance entre le client et le serveur. Elle permet également de ne pas avoir à maintenir une connexion permanente entre le client et le serveur. Le serveur peut ainsi répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication. Cela devient essentiel dans un système distribué. L’absence de gestion d’état du client sur le serveur permet également une répartition des requêtes sur plusieurs serveurs : une session client n’est pas à maintenir sur un serveur en particulier (via une sticky session d’un loadbalancer), ou à propager sur tous les serveurs (avec des problématiques de fraîcheur de session). Cela permet aussi une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajouté facilement pour augmenter la capacité de traitement, ou pour en remplacer un autre). Dans un contexte Web l’utilisation du protocole HTTP en tirant parti de son enveloppe et ses en-têtes. l’utilisation d’URI comme représentant d’une ressource permet d'avoir un système universel d'identification des éléments de l'application. la nature auto-descriptive du message permet la mise en place de serveurs cache. Les informations nécessaires sur la fraîcheur, la péremption de la ressource sont contenues dans le message lui-même Exposé - Informatique & Réseaux

Inconvénients/Limitations de rest La sécurité est inexistante – Utilisation d’HTTPS + Authentification Le client doit conserver des données localement (stateless) Consommation en bande passante – Données de session Peut être problématique pour les Smartphones Le principal inconvénient de REST est la nécessité pour le client de conserver localement toutes les données nécessaires au bon déroulement d’une requête, ce qui induit une consommation en bande passante réseau plus grande. Notamment dans l'univers des appareils mobiles, chaque aller-retour de connexion est consommateur d'électricité. La latence de la connexion rend également l'interaction moins fluide. Exposé - Informatique & Réseaux

Introduction Présentation de Rest Serveur Java JAX-RS Démonstration C’est quoi ? A quoi cela correspond ? Exposé - Informatique & Réseaux

Rest & Java - Spécification JAX-RS REST and Java Java API for RESTFful web Services JSR 311 - JSR 339 Version 2.0 Mise en oeuvre sur un serveur d’application Le développement des services Web repose sur l’utilisation de classes Java et d’annotations. JSR 311 - JAX-RS: The JavaTM API for RESTful Web Services JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services Exposé - Informatique & Réseaux

Spécification JAS-RX Plusieurs implémentations possibles de la spécification JAX-RS JERSEY : Oracle Jersey.java.net CXF : Apache Xxf.apache.org RESTEasy : Jboss Jboss.org/resteasy RESTlet Restlet.com Exposé - Informatique & Réseaux

JAX-RS : Architecture Exposé - Informatique & Réseaux

HELLO WORLD Définition d’un chemin pour associer la ressource hello a une URL Lecture de la ressource HelloWorld via une requete HTTP de type GET @Path("/helloworld") public class HelloWorldRestful { @GET @Produce(MediaType.Html) public String getHelloWorld(){ // Code source associé Return « Hello World »; } Exposé - Informatique & Réseaux

Fil rouge : Gestion d’une bibliothèque Présentation des contextes JAX-RS : Gestion d’une bibliothèque Présentation des annotations Jax-RS Mise en place d’un système CRUD ( Create – Read – Update – Delete) Bibliothèque & livres = Ressources Une bibliothèque est composée de livre On peut lire - ajouter – supprimer – mettre a jour un livre On peut effectuer une recherche en fonction de critères (ISBN et auteur ) On peut acceder a tous les livres présent dans la bibliothèque Exposé - Informatique & Réseaux

@Path Une classe java doit être annotée par @Path pour qu’elle soit traitée par des requêtes HTTP L’annotation @Path sur une classe définit des ressources racines (Root Resources Class) La valeur donnée à @Path correspond à une expression URL relative au contexte de l’application Web http://localhost:8080/MyRestService/Library Permet d’accéder à la bibliothèque L’annotation @Path sur une méthode permet de spécifier le traitement Adresse : localhost Port : 8080 MyRESTWebService : Contexte URL de la ressource : robots Exposé - Informatique & Réseaux

@Path L’annotation @Path peut également annoter des méthodes de la classe L’URL est la concaténation du @Path de la classe et du @Path de la méthode Exemple : Je veux tous les livre d’un auteur précis @Path(«/book/author-{author} ») @GET @Path(« author/{author} ») public void getByAuthor(@PathParam(« author » String author){ // Do Something } Exposé - Informatique & Réseaux

Méthodes HTTP : @GET, @POST, @PUT, @DELETE L’annotation des méthodes Java permet de traiter des requêtes HTTP suivant le type de méthode (GET,POST..) Annotation disponibles : @GET, @POST, @PUT, @DELETE et @HEAD Uniquement utilisable sur des méthodes Java et non sur des classes Le nom de la méthode importe peu. C’est l’annotation qui importe et qui permet d’aiguiller la requête. Opération CRUD sur les ressources Exposé - Informatique & Réseaux

@PathParam – Template parameters Possibilité de définir des expressions plus complexes appelées Template Parameters Le client envoie des informations dans l’url Contenu limité par { … } Spécifie l’isbn du livre recherché Spécifie l’auteur dont on veut récupérer les livres Exposé - Informatique & Réseaux

@PathParam @GET @Path(« ibsn/{isbn} ») public void getByIsbn(@PathParam(« isbn » int isbn){ System.out.println(« isbn »); } @GET @Path(« author/{author} ») public void getByAuthor(@PathParam(« author » String author){ System.out.println(« author »); Exposé - Informatique & Réseaux

Représentation @Consumes @Produces L’annotation @Consumes est utilisée pour spécifier le / les types MIME qu’une méthode de ressource peut accepter L’annotation @Produces est utilisée pour spécifier le / les types MIME qu’une méthode de ressource peut produire Information présente dans l’entête HTTP – Content-Type La liste des constantes des différents type MIME est disponible dans la classe MediaType 1 - Définit ce qui peut être consommé par le système 2 - Définit ce qui peut être produit par le système En plus des types MIME classique : XML / JSON / HTTP / Jersey peut automatiquement effectuer des opérations de sérialisation / désérialisation vers un type Java particulier On peut donc direcement manipuler des objets Java sans passer par une représentation XML ou JSON Annoté par @XmlRootElement / @XmlType et Mappée par un objet JAXBElement Exposé - Informatique & Réseaux

Démonstration Exposé - Informatique & Réseaux

Conclusion A retenir : Rest Architecture systèmes distribués Une ressource distribuée sur un serveur distant Un identifiant de ressource : URL Des « verbe » HTTP permettant la communication client / serveur Une représentation de la ressource Exposé - Informatique & Réseaux

Merci Questions ? Exposé - Informatique & Réseaux