Pause-Café Volubis

pause-café

rendez-vous technique
Pause-Café est une réunion technique
destinée aux informaticiens sur plateforme IBM i.
Elle a lieu 3 fois par an : en Bretagne et sur internet.

Pause-café #78

Avril 2018
le 5 Avril à Guipry (la Minoterie.) , le 4 par Internet

SOA


Architecture SOA
   

Un web-service : c'est un logiciel qui interagis avec d'autres au moyen de protocoles universels (Http, Xml/Json, ...)



REST vs SOAP

La différence majeure est le degré de liaison entre le client et le serveur. Un client développé avec le protocole SOAP est étroitement lié au serveur, par un contrat (WSDL, comme une interface java). Si une modification est effectuée, l'ensemble peut ne plus fonctionner. Il faut effectuer des mises à jour du client s'il y a des changements sur le serveur.


Architecture REST

On dit qu'avec SOAP vous utilisez une enveloppe, avec REST une carte postale ;-)

 

 REST (Representational State Transfert) ou RESTful est un style d’architecture permettant de construire des applications (Web, Intranet, Web Service). Il s’agit d’un ensemble de conventions et de bonnes pratiques à respecter et non d’une technologie à part entière. L’architecture REST utilise les spécifications originelles du protocole HTTP, plutôt que de réinventer une surcouche (comme le fait SOAP par exemple).

règles à suivre pour implémenter REST

Règle n°1 : l’URI comme identifiant des ressources

REST se base sur les URI (Uniform Resource Identifier) afin d’identifier une ressource. Ainsi une application se doit de construire ses URI (et donc ses URL) de manière précise, en tenant compte des contraintes REST. Il est nécessaire de prendre en compte la hiérarchie des ressources et la sémantique des URL pour les éditer :

Quelques exemples de construction d’URL avec RESTful :

Liste des producteurs

Non : http://ventedevins.com/producteur
Oui: http://ventedevins.com/producteurs

Filtre et tri sur les producteurs

Non : http://ventedevins.com/producteurs/filtre/madiran/tri/asc
Oui : http://ventedevins.com/producteurs?filtre=madiran&tri=asc

Affichage d’un producteur

Non : http://ventedevins.com/producteur/voir/87
Oui : http://ventedevins.com/producteur/87

Tous les vins d'un producteur

Non : http://ventedevins.com/producteur/vins/87
Oui : http://ventedevins.com/producteur/87/vins

Affichage d’un vin d'un producteur

Non : http://ventedevins.com/producteur/vin/87/1568
Oui : http://ventedevins.com/producteur/87/vin/1568

En construisant correctement les URI, il est possible de les trier, de les hiérarchiser et donc d’améliorer la compréhension du système.

L’URL suivante peut alors être décomposée logiquement :

http://ventedevins.com/producteur/87/vin/1568 => le vin 1568 du producteur 87
http://ventedevins.com/producteurs/87/vins => tous les vins du producteur 87
http://ventedevins.com/producteur/87 => un producteur
http://ventedevins.com/producteurs => tous les producteurs

Règle n°2 : les verbes HTTP comme identifiant des opérations

La seconde règle d’une architecture REST est d’utiliser les verbes HTTP existants plutôt que d’inclure l’opération dans l’URI de la ressource. Ainsi, généralement pour une ressource, il y a 4 opérations possibles (CRUD) :

  • Créer (create)
  • Afficher (read)
  • Mettre à jour (update)
  • Supprimer (delete)

HTTP propose les verbes correspondant :

  • Créer (create) => POST
  • Afficher (read) => GET
  • Mettre à jour (update) => PUT
  • Supprimer (delete) => DELETE

Exemple d’URL pour une ressource donnée (un livre par exemple) :

Créer un producteur

Non : GET http://ventedevins.com/producteur/create
Oui : POST http://ventedevins.com/producteur

Afficher

Non : GET http://ventedevins.com/producteur/voir/87
Oui : GET http://ventedevins.com/producteur/87

Mettre à jour

Non : POST http://ventedevins.com/producteur/editer/87
Oui : PUT http://ventedevins.com/producteur/87

Supprimer

Non : GET http://ventedevins.com/producteur/87/delete
Oui : DELETE http://ventedevins.com/producteur/87

Le serveur peut renvoyer les opérations acceptées sur une ressource via l’entête HTTP Allow.

Règle n°3 : les réponses HTTP comme représentation des ressources

Il est important d’avoir à l’esprit que la réponse envoyée n’est pas une ressource, c’est la représentation d’une ressource. Ainsi, une ressource peut avoir plusieurs représentations dans des formats divers : HTML, XML, CSV, JSON, etc.

C’est au client de définir quel format de réponse il souhaite reçevoir via l’entête Accept. Il est possible de définir plusieurs formats.

Quelques exemples :

Réponse en HTML

GET /producteurs
Host: ventedevins.com
Accept: text/html

Réponse en XML

GET /producteurs
Host: ventedevins.com
Accept: application/xml


Exemples

Les mails GMAIL sont accessibles depuis un navigateur (c'est même un peu le principe de base)
• Mais aussi en web service REST :
-- lecture de mes mails chez google, penser à changer le mot de passe -;)

SELECT *
FROM XMLTABLE('$result/*[local-name()=''feed'']/*[local-name()=''entry'']'
PASSING
XMLPARSE(DOCUMENT
systools.HTTPGETBLOB('https://af400Volubis:motdepasse@gmail.google.com/mail/feed/atom/','')) AS "result"
COLUMNS
title VARCHAR(128) PATH '*[local-name()=''title'']',
summary VARCHAR(1024) PATH '*[local-name()=''summary'']',
author_name VARCHAR(255) PATH '*[local-name()=''author'']/*[local-name()=''name'']',
author_email VARCHAR(255) PATH '*[local-name()=''author'']/*[local-name()=''email'']' )
AS RESULT;

• Lecture des taux de change de l'Euro sur le site de la BCE



ici nous utilisons la fonction verbeuse de HttpGetClob afin de récupérer aussi les entêtes HTTP dans lesquelles il y a le code HTTP (200/404)

• retour en JSON

Avec des données OpenData de la ville de Nantes (voir http://data.nantes.fr)

 

• Watson

 

Découverte de l'API "translate"



Cette API, appelée depuis un navigateur, retourne du texte (par défaut) :

 

Exemple d'utilisation en PHP (inspiré de l'exemple trouvé sur http://yips.idevcloud.com/wiki/index.php/Watson/Watson)


Résultat


Autre test, cette fois en RPG, et en utilisant un DSPF ;-)


Résultat

 



Pour la partie serveur, nous avons plusieurs possibilités pour faire des API Rest :

  1. Faire des web services en PHP avec Zend
  2. Utiliser un des produits Open sources de 5733OPS

    le projet DashforIBMi montre bien la puissance de Node.js, par exemple.

      Il est basé sur une architecture modèle/vue/contrôleur

        Les vues étant réalisées à l'aide jade , template de représentation (génération de html, déjà déprecié)

  3. Au niveau serveur IBMi, tout cela est fortement basé sur "IBM i Services" (accès aux infos système en SQL)


    Voici le résultat


  4. Utiliser le serveur d'applications intégré (IWS)
  5. ou le serveur de web services (même produit)


Avec ce dernier, nous savons transformer des programmes RPG historiques en web services, voyez notre session de Mai 2017

 

En résumé :

•Nous nous connectons sur le serveur d'administration (JOB Admin) sur le port IP 2001


•Sur un serveur nouvellement créé, un service (convertTemp) est fourni en démo, pour créer les autres :

•Choix du type :



 

 

 

 

Et voilà


• Testons

 


Améliorations récentes

 

ADDENVVAR ENVVAR(QIBM_RPG_PCML_VERSION) VALUE(7.0) LEVEL(*SYS)            

Autres nouveautés de la TR4 (7.3) et TR8 (7.2) (lettre d'annonce)