Resource Oriented Architecture

Page  Ressource Oriented Architecture L’architecture du Web et le REST

Aurélien Pelletier Architecte Logiciel Expertise Java En charge de la veille technologique Web 2.0 au sein du département innovation d’Atos Origin http://blogpro.toutantic.net Qui ? Page 

Page  Objectifs Comprendre le style d’architecture REST Comprendre les différences entre service et ressource

Page  Agenda L’architecture des Mash-Up Crée une application RESTful L’architecture orientée ressource REST Le débat SOAP/REST Ressources & Services

L’approche REST HTTP URI XML Abstraction ( Web 2.0) ‏ ROA Technologies Style d'architecture Architecture Technologies

http://dng.org/symposium/2008/ http://dng.org/symposium/2008/sessions http://dng.org/symposium/2008/sessions/ROA http://dng.org/symposium/2008/speakers/aurelien http://dng.org/symposium/2008/participants/ 1 Donner un identifiant unique à toutes les choses intéressantes ou Donner une URI à toutes les ressources Page 

2 Permettre plusieurs représentations Page  Représentation GET http://dng.org/symposium/2008/sessions/day1 Accept : text/html

2 Permettre plusieurs représentations Page  Représentation <sessions> <date>11/02/2008</date> <session id="1"> <time></time> <name>Session Plénière</name> <summary> Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés. </summary> </session> GET http://dng.org/symposium/2008/sessions/day1 Accept : application/xml

2 Permettre plusieurs représentations Page  Représentation <sessions> <date>11/02/2008</date> <session id="1"> <name>Session Plénière</name> </session> GET http://dng.org/symposium/2008/sessions/day1?format=court Accept : application/xml

3 Mettre des liens dans les représentations Page  <sessions> <date>11/02/2008</date> <session id="1"> <time></time> <name>Session Plénière</name> <summary> Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés. </summary> </session> <session id="5" ref=" http://dng.org/symposium/2008/sessions/roa "> <time>16:00 - 17:00</time> <name>Resource Oriented Architecture (ROA)</name> <summary></summary> <speaker ref=" http://dng.org/symposium/2008/speakers/aurelien "> Aurélien Pelletier</speaker> </session>

4 Utiliser l'interface uniforme d'HTTP Page 

GET Page  GET retourne une représentation de l'état courant d'une ressource Get est idempotent La même requête produit à chaque invocation le même résultat sur le serveur. Ne change pas l'état d'une ressource

POST crée une nouvelle ressource C'est le serveur qui décide de l'URI de la nouvelle ressource POST n'est pas idempotent ! Crée une nouvelle URI Page  POST

PUT crée ou modifie une ressource Dans le cas d'une création c'est le client qui décide de l'URI de la ressource Change l'état d'une ressource PUT est idempotent DELETE efface logiquement la ressource DELETE est idempotent Page  PUT & DELETE

HEAD Obtenir uniquement les entêtes OPTIONS Liste des méthodes supportées par une ressource HTML 4 ne supporte que GET et POST Page  OPTION & HEAD

Page  Approche services RPC Calculatrice 4 opérations

Page  Approche ressources REST http://calc/soustraction?val1=xx&val2=yy http://calc/multiplication?val1=xx&val2=yy http://calc/addition?val1=xx&val2=yy http://calc/division?val1=xx&val2=yy Calculatrice 4 opérations

Calculatrice 4 opérations Page  http://calc/chiffres/1 http://calc/operations/division http://calc/operations/addition http://calc/operations/... http://calc/calculs/ http://calc/nombres/ Approche ressources REST

Page  Calculatrice 4 opérations PUT /nombres/douze HTTP/1.1 Host: calc <nombre> <dizaine> http://calc/chiffres/1 <dizaine> <unite> http://calc/chiffres/2 <unite> </nombre> 201 Created POST /calculs/ HTTP 1.1 Host: calc <calcul> <nombre> http://calc/ nombres/douze </nombre> <operation> http://calc/operation/addition </operation> <nombre> http://calc/ nombres/cinq </nombre> <calcul> 201 Created Location: http://calc/calculs/UID <result>17</result> Requête Réponse

Page  Calculatrice 4 opérations GET /calculs/UID HTTP/1.1 Host: calc 200 OK <calcul> <nombre> http://calc/ nombres/douze </nombre> <operation>http://calc/operation/addition</operation> <nombre> http://calc/ nombres/cinq </nombre> <result ref ="http://calc/nombres/resultUID">17</result> <calcul>

Application RESTful 1 Identifier les ressources 2 Définir les représentations 3 Relier les représentations par des liens 4 Utiliser l’interface uniforme

Page  Architecture Orientée Ressource

4 ième génération d'architecture Net - Ware 3 tiers Client léger Hard - Ware Mainframe Client passif Soft - Ware Client-server Client lourd Info - Ware ROA Client riche

Page  Affichage Construction des écrans Traitements métiers Données persistantes Données de sessions Mainframe / Client passif

Page  Interface ODBC/JDBC/... Poste client Base de données Client-serveur / Client lourd

3 tiers / Client léger Page  Interface HTTP Navigateur Base de données Serveur d'applications Interface ODBC/JDBC/...

ROA / Client riche Page  Interface de services Ressources Client riche Serveur d'applications Base de données Interface ODBC/JDBC/...

Identifiant, ressource, représentation Page  Architecture of the World Wide Web, Volume One W3C Recommendation 15 December 2004 http://www.w3.org/TR/webarch/

Cool URI don't change L'URI fait partie de l'interface publique URI are opaque Utiliser des URI logiques plutôt que physiques: http://dng.org/symposium/2007/sessions.html => Couplage faible => Evolutivité => Lisibilité Cool URI don't change Page 

Page  Representational State Transfer REST Le terme provient de la thèse de Roy Fielding en 2000 - principal architecte d'HTTP 1.1 - co-auteur de la spécification des URI. L'appel à GET transfère la représentation d'une ressource. Cette représentation place le client dans un certain état. Suivre un lien va transférer une nouvelle représentation et changer l'état du client. => Representational State Transfer

Page  Representational State Transfer REST est un style d'architecture Un style d'architecture est un ensemble de contraintes cohérentes qui en limitant un système lui procure des propriétés désirées. REST capture les principes fondamentaux qui font le succès du Web. REST décrit les contraintes qui permettent au web d'être simple, performant, fiable, scalable et évolutif

Envoyer un message sur le réseau Page 

Page  Principes d'architecture généraux

Page  Principes d'architecture généraux Système en couche Capacité à monter en charge Sécurité Intégration au legacy Code à la demande (optionnel) Evolutivité Javascript => AJAX

Interface uniforme Fonctionne avec 4 contraintes complémentaires Identification des ressources (URI) Manipulation des ressources par des représentations Messages auto-descriptif L’Hypermedia comme moteur de l’état de l’application L’interface uniforme (principe de généricité) + Simplicité + Evolutivité - Efficacité

Le débat: SOAP vs REST Page 

Ressources et Services Page  Objectif Style d'architecture REST SOAP WSDL UDDI WS-* HTTP URI XML Aligner l'IT sur le métier Aligner l'IT sur le Web SOA Ressources Services + Architecture ROA Technologies

Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans d’HTTP seul HTTP vs SOAP Technologies

Web Services = SOAP + WSDL + UDDI +WS-* Où est le Web dans ces Web Services ? - Mauvaise utilisation du protocole HTTP - Pas d'URI Il faut trouver un autre nom Big Web Services vs Light Web Services Un service web léger est un site web navigable par les machines Page  Web Services ?

Page  WS-* est trop complexe Ce sont les « big vendors » qui ont inventé et poussent SOAP / WS-*

Interopérabilité Page  SOAP WS-* => Design by commitee Interopérabilité moyenne REST s'appuie sur des standards existant et largement répandu: Identification des ressources URI Transport et l'interface générique HTTP Représentations HTML , XML, gif, ... Type Mime Des clients HTTP et des parseurs XML de qualité sont disponibles pour tous les langages Véritable Interopérabilité SOAP/WS-* sont les DRM de la SOA, HTTP en est le MP3.

Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans de SOAP HTTP vs SOAP Technologies

Page  Fonctionnalités avancées

Page  Conversation machine to machine HTTP + XML fonctionne très bien pour les échanges Humain/serveur au travers d'un navigateur. SOAP/WS-* est plus adapté pour des échanges bidirectionnels entre composants serveur machine to machine.

REST-ROA / SOA Page  Style d'architecture REST SOA Architecture ROA

REST-ROA / SOA Page  REST/ROA Un travail théorique de référence (thèse de Fielding)‏ Une architecture: celle définie par le W3C Une implémentation: le Web Des principes et des contraintes d'architectures bien définis Approche bottom-up Hérite de la culture du Web SOA Englobe le style d'architecture et les architectures Pas de contraintes d'architectures ou de principe universellement reconnus Approche bottom-up Hérite de la culture Entreprise et RPC/CORBA/DCOM

Ressources et Services Page  Ressources Services

Ressources et Services Page  Une seule interface uniforme générique Plusieurs interfaces spécialisées Verbes Noms Services Ressources Orienté données Plus de possibilités de réutilisation Moins de contrôle Plus de simplicité Orienté traitement Meilleure efficacité Plus de contrôle Plus de complexité

Accéder à une donnée avec un service? getFacture(Identifiant)‏ serialization/deserialization XML Accéder à un traitement avec une ressource? Une ressource est une abstraction on peut mapper un traitement sur une ressource. Ce n'est pas toujours pertinent (service de conversion de température)‏ En mappant un traitement sur une ressource on lui donne une URI (utile pour retrouver une commande)‏ Il faut faire de l'URI design nouvelle compétence Ressources et Services Page 

Ressources et Services Page  Traitements Données Back end Front end Services SOA SOAP/WS-* Ressources REST HTTP

Softwares + Services + Ressources Page  procédural Objet Service Service procédural Objet procédural procédural Objet Ressource

Page  “ 25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a Service d'ici 2011” Fin du débat propriétaire VS open source Importance du lock-in par les données. L'important est/sera la portabilité des données Open Data Softwares + Services + Ressources

Intéropérabilité (HTTP + XML) + Adressabilité (URI)‏ Surface de contact plus grande avec les applications Favorise la sérendipité ( serenpidity ) « L'art de faire une découverte intéressante en cherchant autre chose » Donc l'innovation Innovation Page 

Le nouveau testament Page 

Les apôtres Pete Lacey http://wanderingbarque.com/nonintersecting/ Stefan Tilkov http://www.innoq.com/blog/st/ Bill de Hora http://dehora.net/journal/ Mark Baker http://www.markbaker.ca Steve Vinoski http://steve.vinoski.net/blog/ Stuart Charlton http://www.stucharlton.com ... YOU ? Page 

Conclusion Page  4ième génération d'architecture Softwares + Services + Ressources Open Data L'approche orienté ressources + interface uniforme est l’un des moteurs de l'innovation sur le Web

- IstockPhoto pour les photos - Le projet Crystal pour les icônes - Mes collègues d'Atos Origin pour leurs retours critiques Remerciements

HTTP ne garanti pas la livraison d'un message Mais GET/PUT/DELETE sont idempotent On peut renouveler l'appel jusqu'à obtenir une réponse Problème avec POST Utiliser une « ressource factory » pour obtenir une url pointant vers une ressource « vide » Utiliser PUT Page  Comment gérer la fiabilité en HTTP

Resource Oriented Architecture

Contenu connexe

Similaire à Resource Oriented Architecture

Plus de DNG Consulting

Resource Oriented Architecture

Notes de l'éditeur