API RESTful 
Retour d’expérience 
Christophe Laprun / @metacosm 
Jahia Solutions Group SA
REST? 
• REpresentational State Transfert 
• “Architectural style for distributed 
hypermedia system” - Roy Fielding
REST? 
• Certes… mais plus concrètement? 
• Ensemble de contraintes pour le web donc 
HTTP
Client - serveur 
• Séparation des clients et des serveurs 
• Serveur publie une collection de 
“resources”… 
• … que les ...
Serveur sans état 
• Toutes les requêtes doivent contenir toutes 
les informations nécessaires pour que le 
serveur puisse...
Caches 
• Les réponses peuvent être cachées par les 
clients 
• Une réponse doit établir sous quelles 
conditions elle peu...
Interface uniforme 
• Identification des resources 
• Manipulation des resources via leur 
représentations 
• Messages aut...
Système à couche 
• L’architecture doit prendre en compte et 
permettre l’existence potentielle d’éléments 
intermédiaires...
Code à la demande 
(optionnel) 
• Clients peuvent être étendus en 
demandant du code au serveur
Contraintes 
• Pourquoi?
Caractéristiques 
architecturales 
• Performance 
• Évolutivité (changement / charge) 
• Simplicité 
• Modifiabilité 
• Vi...
Contraintes? 
• Les 3 premières contraintes permettent 
une architecture web scalable et 
performante: 
• Couplage faible ...
Contraintes? 
• La 5ème contrainte permet de gérer la 
performance/évolutivité (load-balancers), la 
sécurité (firewall) e...
4ème contrainte? 
• Le vrai centre des architectures REST 
• Unifie l’interface entre les différentes 
parties de l’archit...
API RESTful? 
• Techniquement, on doit parler d’API 
RESTful, pas d’API REST 
• Une API qui respecte les principes de 
l’a...
API RESTful? 
• Certes… mais plus concrètement?
API RESTful? 
• Beaucoup (tout?) réside sur comment 
respecter le principe d’interface uniforme
RESTful? 
• GET: /getAllClients 
• GET: /addClient?id=foo 
• GET: /invoiceClient?client=foo&id=1234
Questions pertinentes 
• Quelles sont les resources que le serveur 
expose? 
• Comment sont-elles identifiées (URIs)? 
• C...
Modèle de maturité de 
Richardson
Niveau 1: resources 
• Resources sont identifiées avec URI 
• Tunneling des requêtes (GET ou POST) 
• Pas de sémantique
Resources 
• Noms, pas verbes 
• Similaire à une conception orientée objet 
• Uniform Resource Identifier (URI) associé 
à...
Niveau 2: verbes HTTP 
• Multiples resources 
• Utilisation sémantiquement correcte des 
verbes HTTP 
• Utilisation correc...
Sémantique méthodes 
HTTP 
• CRUD operations 
• POST / PUT: création 
• GET: lecture 
• PUT / POST: mise à jour 
• DELETE:...
Niveau 3: contrôles 
hypermédia 
• Resources auto-descriptives 
• État ET comportement accessible via les 
représentations...
Représentations 
• Les clients n’ont pas accès aux resources, 
seulement leur représentations 
• Doivent contenir suffisam...
Choix du content-type 
• Dépend des clients cibles 
• Négociation de contenu 
• Réutiliser un media type existant ou 
déve...
Cas d’utilisation: JCR 
• Besoin: exposer un repository JCR via une 
architecture REST 
• Optimisé pour un accès facilité ...
Aperçu JCR 
• Java Content Repository 
• Modèle de données et services associés 
pour le stockage et la manipulation de 
c...
Aperçu JCR 
• Item: 
• Type 
• Path 
• Node: 
• Identifiant 
• Enfants 
• Propriétés 
• Mixins 
• Versions 
• Property: 
•...
Aperçu JCR
Resources 
• Mapping assez simple dans notre cas: 
resource => node
Sémantique HTTP 
• CRUD sur les noeuds JCR 
• Mapping assez simple encore une fois 
• Mais: 
• Liberté sur la sémantique P...
Représentations 
• JSON seul 
• augmenté de Hypertext Application 
Language 
• Content-type: application/hal+json
RESTful? 
• Sémantique des verbes HTTP? 
• Transition d’état par les liens? 
• Pas de media type propre 
• Versionning dan...
Références 
• La thèse de Roy Fielding: http:// 
www.ics.uci.edu/~fielding/pubs/ 
dissertation/top.htm 
• RESTful Web Serv...
Prochain SlideShare
Chargement dans…5
×

RESTful API - Retour d'expérience

1 051 vues

Publié le

Un retour d'expérience concernant l'implémentation d'une nouvelle API RESTful pour exposer du contenu JCR au sein d'une installation Jahia Digital Factory.

Publié dans : Logiciels
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 051
Sur SlideShare
0
Issues des intégrations
0
Intégrations
16
Actions
Partages
0
Téléchargements
35
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

RESTful API - Retour d'expérience

  1. 1. API RESTful Retour d’expérience Christophe Laprun / @metacosm Jahia Solutions Group SA
  2. 2. REST? • REpresentational State Transfert • “Architectural style for distributed hypermedia system” - Roy Fielding
  3. 3. REST? • Certes… mais plus concrètement? • Ensemble de contraintes pour le web donc HTTP
  4. 4. Client - serveur • Séparation des clients et des serveurs • Serveur publie une collection de “resources”… • … que les clients peuvent manipuler via leur représentations
  5. 5. Serveur sans état • Toutes les requêtes doivent contenir toutes les informations nécessaires pour que le serveur puisse y répondre
  6. 6. Caches • Les réponses peuvent être cachées par les clients • Une réponse doit établir sous quelles conditions elle peut être cachée
  7. 7. Interface uniforme • Identification des resources • Manipulation des resources via leur représentations • Messages auto-descriptifs • Hypermedia As The Engine Of Application State (HATEOAS)
  8. 8. Système à couche • L’architecture doit prendre en compte et permettre l’existence potentielle d’éléments intermédiaires entre le client et le serveur • Requêtes et réponses peuvent être modifiées de manière transparente
  9. 9. Code à la demande (optionnel) • Clients peuvent être étendus en demandant du code au serveur
  10. 10. Contraintes • Pourquoi?
  11. 11. Caractéristiques architecturales • Performance • Évolutivité (changement / charge) • Simplicité • Modifiabilité • Visibilité des interactions (monitoring) • Portabilité • Fiabilité
  12. 12. Contraintes? • Les 3 premières contraintes permettent une architecture web scalable et performante: • Couplage faible client / serveur (évolutivité) • Pas d’état géré par le serveur: multi-threading, clustering facilités • Performance via caches
  13. 13. Contraintes? • La 5ème contrainte permet de gérer la performance/évolutivité (load-balancers), la sécurité (firewall) et l’encapsulation (gateway) de manière transparente • La 6ème contrainte permet au serveur de déléguer une partie du travail aux clients (scripts, applets)
  14. 14. 4ème contrainte? • Le vrai centre des architectures REST • Unifie l’interface entre les différentes parties de l’architecture • Permet de créer une architecture similaire aux pipes UNIX
  15. 15. API RESTful? • Techniquement, on doit parler d’API RESTful, pas d’API REST • Une API qui respecte les principes de l’architecture REST
  16. 16. API RESTful? • Certes… mais plus concrètement?
  17. 17. API RESTful? • Beaucoup (tout?) réside sur comment respecter le principe d’interface uniforme
  18. 18. RESTful? • GET: /getAllClients • GET: /addClient?id=foo • GET: /invoiceClient?client=foo&id=1234
  19. 19. Questions pertinentes • Quelles sont les resources que le serveur expose? • Comment sont-elles identifiées (URIs)? • Comment sont-elles représentées? • Comment mapper le fonctionnel sur la sémantique réduite des verbes HTTP? • Comment gérer l’état dans une architecture stateless?
  20. 20. Modèle de maturité de Richardson
  21. 21. Niveau 1: resources • Resources sont identifiées avec URI • Tunneling des requêtes (GET ou POST) • Pas de sémantique
  22. 22. Resources • Noms, pas verbes • Similaire à une conception orientée objet • Uniform Resource Identifier (URI) associé à chaque resource
  23. 23. Niveau 2: verbes HTTP • Multiples resources • Utilisation sémantiquement correcte des verbes HTTP • Utilisation correcte des code de réponse
  24. 24. Sémantique méthodes HTTP • CRUD operations • POST / PUT: création • GET: lecture • PUT / POST: mise à jour • DELETE: destruction
  25. 25. Niveau 3: contrôles hypermédia • Resources auto-descriptives • État ET comportement accessible via les représentations • HATEOAS
  26. 26. Représentations • Les clients n’ont pas accès aux resources, seulement leur représentations • Doivent contenir suffisamment d’informations pour assurer les transitions d’état
  27. 27. Choix du content-type • Dépend des clients cibles • Négociation de contenu • Réutiliser un media type existant ou développer un media type propre?
  28. 28. Cas d’utilisation: JCR • Besoin: exposer un repository JCR via une architecture REST • Optimisé pour un accès facilité via JS
  29. 29. Aperçu JCR • Java Content Repository • Modèle de données et services associés pour le stockage et la manipulation de contenu numérique • Repository: ensemble de workspaces • Workspace: graphe orienté acyclique • Sommets: Items (Node / Property) • Arcs: relation parent - fils
  30. 30. Aperçu JCR • Item: • Type • Path • Node: • Identifiant • Enfants • Propriétés • Mixins • Versions • Property: • Valeur(s)
  31. 31. Aperçu JCR
  32. 32. Resources • Mapping assez simple dans notre cas: resource => node
  33. 33. Sémantique HTTP • CRUD sur les noeuds JCR • Mapping assez simple encore une fois • Mais: • Liberté sur la sémantique PUT/POST vs. PATCH
  34. 34. Représentations • JSON seul • augmenté de Hypertext Application Language • Content-type: application/hal+json
  35. 35. RESTful? • Sémantique des verbes HTTP? • Transition d’état par les liens? • Pas de media type propre • Versionning dans les URLs vs. via media type
  36. 36. Références • La thèse de Roy Fielding: http:// www.ics.uci.edu/~fielding/pubs/ dissertation/top.htm • RESTful Web Services Cookbook (Allamaraju - O’Reilly) • RESTful Web APIs (Richardson / Amundsen - O’Reilly) • HAL: https://tools.ietf.org/html/draft-kelly-json- hal-06

×