RESTful API - Retour d'expérience

977 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
977
Sur SlideShare
0
Issues des intégrations
0
Intégrations
15
Actions
Partages
0
Téléchargements
33
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

×