Au menu aujourd’hui, un sujet tr\u00e8s tendance: REST. Abord\u00e9\u00a0 par le biais de l’Architecture Orient\u00e9 Ressource (ou ROA: Resource Oriented Architecture), autrement dit, comment cr\u00e9er une architecture de service bas\u00e9 sur REST.<\/p>\n
Comme toujours, commen\u00e7ons par quelques d\u00e9finitions. Je vais les faire assez th\u00e9orique sinon apr\u00e8s, il ne me restera plus rien \u00e0 dire :)<\/p>\n
REST est un design pattern (ou patron de conception) pour l’impl\u00e9mentation de syst\u00e8me connect\u00e9. Ce n’est ni une technologie ni un standard; c’est un type d’architecture pour l’exposition de ressources sur le web.<\/p>\n
L’architecture RESTful adh\u00e8res \u00e0 plusieurs principes :<\/p>\n
Partie la plus importante d’une architecture REST, la strat\u00e9gie de cr\u00e9ation des URL vers les ressources. Son importance vient du fait que les URL d\u00e9finissent les ressources. Et qu’un bonne strat\u00e9gie dans la d\u00e9finition d’URL va simplifier l’utilisation des ressources dans un mode service.<\/p>\n
Voici un exemple, tir\u00e9e de best-practice autour de la d\u00e9finition des URL de ressources:<\/p>\n
A ceux-xi on peut ajouter d’autres conseil qui ne font pas partie r\u00e9ellement des standard d’utilisation de REST mais qui permettent de faciliter l’utilisation de REST en tant qu’architecture de services web<\/p>\n
Voici quelques exemples:<\/p>\n
En sp\u00e9cifiant une extension diff\u00e9rente dans l’URL, on peut demander \u00e0 notre application de services web des repr\u00e9sentation diff\u00e9rentes sur une ressource.<\/p>\n
Voici un exemples de repr\u00e9sentation utile qui peuvent \u00eatre impl\u00e9ment\u00e9e et une suggestion des extensions \u00e0 utiliser:<\/p>\n
Lors de la d\u00e9finition de votre architecture orient\u00e9e services, vous choisirez les types de repr\u00e9sentation n\u00e9cessaire (m\u00eame si je vous conseil d’en utiliser le plus possible), n’oubliez pas que m\u00eame si votre architecture supporte toutes ces extensions, vous pouvez les impl\u00e9menter sur une ressource uniquement si cela est n\u00e9cessaire. Toutes les ressources ne doivent pas obligatoirement impl\u00e9menter toutes les repr\u00e9sentation.<\/p>\n
Mais pensez bien que si votre application est facilement testable, dans un browser par exemple gr\u00e2ce \u00e0 des flux ATOM et des repr\u00e9sentation HTML c’est un plus non n\u00e9gligeable. Je conseil donc l’utilisation de repr\u00e9sentation ATOM pour les listes et HTML pour les ressources.\nPour faciliter le tests, li\u00e9e le plus possible les ressources les unes entre les autres (une liste contient les liens vers les ressources qu’elle liste) et, par exemple, cr\u00e9er des flux ATOM de liste d’exemple de vos ressources (un flux ATOM \u00e0 la racine qui liste tout les package de ressource et un flux ATOM pour chaque package qui liste une s\u00e9rie d’exemple et votre application devient navigable facilement!)<\/p>\n
Les microformats ne font pas partie de la sp\u00e9cification REST et ne devrait peut-\u00eatre pas pas \u00eatre \u00e9voqu\u00e9 ici mais je pense qu’ils peuvent apporter un plus r\u00e9el dans l’aspect service.<\/p>\n
Un microformat HTML est un ensemble de tags HTML et de classes CSS qui permettent de d\u00e9finir un pattern r\u00e9utilisable. Ainsi, \u00e0 chaque fois qu’on veut repr\u00e9senter de mani\u00e8re HTML un objet, on utilise le m\u00eame ensemble de classes CSS et tags HTML ce qui permet de standardiser vos repr\u00e9sentation et de facilement reconna\u00eetre dans vos HTML tel ou tel objet.<\/p>\n
Pour en savoir plus, c’est ici: http:\/\/microformats.org\/<\/a><\/a>. Ce site comprend des microformat utilis\u00e9 de par le web et certain design pattern pour la cr\u00e9ation de vos propre microformats.<\/p>\n Un catalogue de microformat \u00e9tant juste l’ensemble des microformats utilis\u00e9 dans votre application (ou dans VOS applications). L’id\u00e9al \u00e9tant bien sur de fournir aux clients de vos application le catalogue en question et les explications sur ce dernier.<\/p>\n Il est conseill\u00e9 d’utiliser les erreurs standard HTTP. Donc, de retourner un statut diff\u00e9rent du statu 200 pour toute requ\u00eate menant \u00e0 une erreur. Il existe de nombreux statut disponible dans la sp\u00e9cification HTTP, pour les erreurs il faut utiliser les statuts dans les plages suivantes: 400 plage pour les erreurs client, 500 plage pour les erreurs serveur.<\/p>\n Voici les erreurs que je vous conseil au minimum<\/strong> d’utiliser:<\/p>\n L’impl\u00e9mentation peut se faire avec de nombreux technologie et framework diff\u00e9rent. Pour n’en citer que quelques un (principalement dan le monde Java, \u00e9tant d\u00e9veloppeut Java):<\/p>\n Pour plus d’info sur Restlet et pour un exemple d’impl\u00e9mentation d’une architecture ROA, venez lire l’article que j’ai \u00e9crit \u00e0 ce sujet: Impl\u00e9menter une architecture de service web RESTfull avec Restlet et son extention Spring<\/a><\/p>","protected":false},"excerpt":{"rendered":" Au menu aujourd’hui, un sujet tr\u00e8s tendance: REST. Abord\u00e9\u00a0 par le biais de l’Architecture Orient\u00e9 Ressource (ou ROA: Resource Oriented Architecture), autrement dit, comment cr\u00e9er une architecture de service bas\u00e9 sur REST. D\u00e9finitions Comme toujours, commen\u00e7ons par quelques d\u00e9finitions. Je vais les faire assez th\u00e9orique sinon apr\u00e8s, il ne me restera plus rien \u00e0 dire \ud83d\ude42 SOA : Service Oriented Architecture : Architecture orient\u00e9e service. ROA : une architecture SOA bas\u00e9e sur des services web RESTful\u00a0 au lieu des services…Gestion des erreurs<\/h3>\n
Impl\u00e9mentation<\/h3>\n