Architecture REST & Web Services

Présentation au sujet: "Architecture REST & Web Services"— Transcription de la présentation:

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

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

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

4 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

5 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

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

7 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

8 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

9 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

10 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

11 Architecture Exposé - Informatique & Réseaux

12 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

13 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

14 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 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

15 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

16 Exemple - Library URL Méthode Action http://locahost:8080/Library GET
Récupération de tous les livres de la bibliothèque. Récupération dans la bibliothèque d’un livre avec id = 12 POST Création d’un livre dans la bibliothèque : Paramètres passées dans le corps de la requête HTTP Création d’un livre dans la bibliothèque avec les paramètres passée via l’URL 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

17 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

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

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

20 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

21 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

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

23 Rest & Java - Spécification JAX-RS
REST and Java Java API for RESTFful web Services JSR 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 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

24 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

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

26 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

27 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

28 @Path Une classe java doit être annotée pour qu’elle soit traitée par des requêtes HTTP sur une classe définit des ressources racines (Root Resources Class) La valeur donnée correspond à une expression URL relative au contexte de l’application Web Permet d’accéder à la bibliothèque 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

29 @Path peut également annoter des méthodes de la classe L’URL est la concaténation de la classe et 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 String author){ // Do Something } Exposé - Informatique & Réseaux

30 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 : 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

31 @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

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

33 Représentation @Consumes @Produces
est utilisée pour spécifier le / les types MIME qu’une méthode de ressource peut accepter 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é et Mappée par un objet JAXBElement Exposé - Informatique & Réseaux

34 Démonstration Exposé - Informatique & Réseaux

35 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

36 Merci Questions ? Exposé - Informatique & Réseaux