Les bases
REST veut dire littéralement Representational State Transfer. Aujourd’hui on parle d’avantage de service RESTfull. Il ne s’agit ni d’un langage de programmation, ni d’un outil de développement. Loin d’être une représentation bien encadrée et standardisé comme SOAP, REST est un style d’architecture qui se veut simple à mettre en œuvre. Même si aujourd’hui REST n’est pas le standard d’un organisme reconnu à l’échelle internationale, il s’appuie sur le protocole HHTTP qui lui par contre a des méthodes standards. De ce fait il sera plus facile pour les services développés en REST, d’implémenter les méthodes CRUD (Create/Read/Update/Delete). REST tout comme HTTP est stateless ou sans état. Il a quand même l’avantage de permettre facilement l’implémentation du cache au niveau applicatif. En plus, combiné au langage comme PHP, REST peut être totalement statefull. Il est d’avantage préféré au SOAP pour sa simplicité même s’il souffre de quelques problèmes clairement identifiés:
- il n’est pas standardisé comme je l’ai déjà dit
- en plus, contrairement à SOAP qui peut faire le WS security, REST n’en est pas capable.
Les différentes méthodes
Pour le support des projets REST, TIBCO met à disposition les méthodes suivantes:
- GET : permet d’accéder à la représentation d’une ressource
- PUT : créer ou mettre à jour une ressource avec une URI connue
- POST : créer une ressource lorsqu’on ne connaît pas l’URI
- DELETE : supprime une ressource.
- PATCH: mise à jour partielle d’une ressource.
Mise en œuvre
Pour mettre en pratique ce que nous venons de dire, je vous propose de créer un projet TIBCO et de le compléter en suivant les étapes ci après :
- Commencer par créer un projet TIBCO, ensuite
- Ajouter un process simple qui va nous permettre d’implémenter le service REST en question,
- Créer un nouveau dossier et ajouter y une ressource pour la connexion HTTP. cette ressource nous permet d’exposer notre ressource REST. N’oubliez pas que dans le cadre de REST, on devrait en réalité parler de ressource et méthode à la place de service et opérations comme pour le cas de SOAP. Pour la configuration de la ressource HTTP, l’on peut bien laisser le nom du host par défaut (localhost). Pour le port, vous pouvez attribuer un port compris entre 0 et 65535. Sans être stupide, veillez à ne pas choisir un port réservé et assurer vous que celui que vous choisissez ne soit pas déjà occupé par un service sur votre poste.
- Ajouter l’activité HTTP Receiver pour intercepter les connexions en entrée. Cette activité doit être configurée par la ressource HTTP créé précédemment.
Procédez de la même façon pour ajouter
- Un service, puis
- une ressource ou plusieurs ressources, et enfin
- une méthode ou plusieurs méhodes. Optionnellement vous pouvez ajouter
- un message Request, et ou
- un message Response
Implémenter la logique métier
Une fois notre interface créée, nous devons implémenter la logique métier. C’est à dire ce que le service est sensé exécuté lorsqu’une requête arrive sur l’activité REST Dispatch and Reply au travers de HTTP Receiver. Dans un premier temps, il faut tout simplement sélectionner le process ver lequel l’exécution est transférée. C’est ce processus qui implémente la logique métier. Pour ce faire, dans le cas de ce tutoriel, je sélectionne d’abord l’opération (listProject), et ensuite, je choisi la méthode (GET dans ce cas). Et finalement sur « Process Name », je peux cliquer sur l’icône présente pour sélectionner le process qui m’interesse.
Effectuer le mapping des données reçues
Mapper les champs du processus qui exécute la logique métier.
A ce point il ne vous reste qu’à tester le service REST.
Tester notre service REST
Pour tester notre service, nous avons besoin de connaitre le WADL. Il s’agit pour ceux qui sont familiers de l’équivalent WSDL pour les services SOAP. Pour obtenir le wadl, il suffit de cliquer sur le nom de l’application (ProjectsResourceApp pour notre cas). Le test peut donc être effectuer soit depuis SOAPUI, ou encore directement depuis un navigateur web avec l’URL du service exposé.
Pour terminer, démarrer votre service à l’url spécifiée et tester que le projet fonctionne.
Client TIBCO
Merci d’avoir suivi ce tutoriel.
Vous êtes Décideur, Dirigeant d’entreprise ou Consultant ?, Vous avez le pouvoir de décision ?
J’ai écrit un livre sur les questions à se poser pour choisir une solution ESB. Vous pouvez demander votre copie gratuite ici et maintenant.
@Dieudonné MIAFFO – A la base je suis ingénieur informaticien de formation, avec une solide culture générale de l’informatique et un goût très prononcé pour les évolutions des systèmes d’information.
Je suis passionné par l’évolution technologique et c’est tout naturellement que j’exerce mon métier d’Architecte Expert ESB.
Je suis diplômé de SUPELEC et depuis 2012 j’interviens sur différents projets de transformation digitale. j’accompagne les entreprises en les aidant à tirer le meilleur de leur système d’information.
Mes sujets d’intérêt concernent principalement les ESB | API et la cybersécurité.
