Services Web REST

Une excellente façon de capitaliser sur son patrimoine applicatif
Vous souhaitez rendre accessible des règles de gestion lourdes et coûteuses depuis des applications web de type Angular ou ReactJS sans réécrire de nouvelles règles ?
 
La solution : transformer vos traitements en service web ! Mais qu’est-ce qu’un service web ?
Quels sont ses avantages ? 
 
Découvrez des éléments de réponse dans cet article ! 
1) Qu’est-ce qu’un service web ?

Les services web permettent à des applications d’interagir à distance via Internet, quelles que soient les plateformes et les langues utilisés.

Et cela grâce à un ensemble de protocoles qui standardisent les modes d’appel et de connexion entre applications.

Ces standards sont :

  • SOAP
  • REST
1.1) SOAP

Le protocole SOAP (Simple Object Access Protocol) définit la structure des messages échangés par les applications via Internet. Il a un format d’échange en XML.

Le WSDL ou (Web Services Description Language), toujours en XML, fournit un mode de description des applications. Ce mode permet d’invoquer les fonctions des applications à distance par l’échange de messages au format SOAP (XML). 

Soap est un protocole officiel régit par le W3C (World Wide Web Consortium).

1.2) REST

REST ou Representational State Transfer est une architecture logicielle pour les systèmes distribués. 

Le principe de REST est de considérer chaque ressource comme une entité unique et de la manipuler à l’aide d’opérations standardisées telles que GET, POST, PUT et DELETE. Les services web REST sont donc des services web qui utilisent l’architecture REST pour communiquer avec d’autres systèmes.

L’architecture REST est basée sur les principes suivants : 

  • Adressabilité : chaque ressource doit être identifiée par un URI unique. 
  • Interface homogène : chaque ressource doit être facilement utilisable grâce à des méthodes standardisées telles que GET, POST, PUT et DELETE.
  • Structure client-serveur : le principe de la structure client-serveur est appliqué lorsque le serveur met un service à disposition qui peut être demandé par un client.
  • Serveur sans état : la communication entre le serveur et le client doit être sans état, car chaque requête du client vers le serveur doit contenir les informations requises afin de permettre au serveur de traiter la requête, sans qu’il n’y ait de dépendance d’un contexte conservé sur le serveur. REST prend en charge les formats XML, JSON, texte brut et HTML. 
2) Les avantages de faire appel à un service web

Les services web ont de nombreux avantages. Parmi eux : 

  • Ils permettent une excellente interopérabilité entre les plateformes puisqu’il permet aux différents logiciels de communiquer facilement entre eux  
  • Ils permettent la réutilisation de services existants dans une autre application web de type react JS ou Augular 
  • Ils utilisent des méthodes standardisées et légères : les webservices possèdent une structure bien définie, reposant sur des protocoles standards 
  • De nombreux utilisateurs peuvent interroger simultanément le serveur distant 
  • Grâce au certificat et au protocole HTTPS, les informations échangées sont chiffrées. 
3) Les services web dans nos produits

Les services web ont été introduits chez NatStar il y a 20 ans. Depuis 15 ans, ils sont générés en JAVA. et peuvent être déployés sur la famille de serveurs jBOSS/Wildfly.

Avec l’évolution des clients Javascript, Nat System a décidé de mettre en avant l’option REST, permettant à ces services de fournir une réponse REST JSON. Ainsi, ils peuvent être directement exploités par divers clients Javascript comme Angular et React.

4) Exemples de mise en oeuvre de services web à partir de NatStar
4.1) L’instruction à transformer en service web
  • Soit l’instruction SelDemo4 prenant comme paramètre :

Et dont le contenu est le suivant :

local THESEG@ p  
local i%  
local cstring id, cur%, REQ$ ,name$, forname$, nom$, prenom$ 
i% = 0 
cur% = sql_openthecursor% 

THINGS_SEQUENCE_ALLOC 32, sizeof THESEG, THINGS_TYPE_SEGMENT%, “!THESEG”, LASEQ 
@p = THESEG(THINGS_SEQUENCE_GET_ENTRY%(LASEQ, i%)) 
nom$ = … 
prenom$ = … 
REQ$ = “SELECT Nom, Prenom, ID INTO :,:,: FROM Demo WHERE NOM = : AND PRENOM = :”

SQL_EXECSTR REQ$, name$, forname$, id, nom$, prenom$  using cur%

if SQL_ERROR% <> 0 
   return 
endIf 
p.nom = name$ 
p.prenom = forname$ 
p.id = ID 
while true% 
   SQL_Exec FETCH using cur% 
   if SQL_ERROR% < 0 
      break 
   elseIf SQL_ERROR% > 0 
      break 
   endIf 
   i% = i% + 1 
   @p = THESEG(THINGS_SEQUENCE_GET_ENTRY%(LASEQ, i%)) 
   p.nom = nom$ 
   p.prenom = prenom$ 
   p.id = ID 
endWhile 
THINGS_SEQUENCE_SET_NB_ENTRY LASEQ, i% + 1 
sql_closethecursor cur%  

  • Le typdef THESEG est base sur un segment de même nom que voici :

SEGMENT THESEG 
CSTRING NOM(255) 
CSTRING PRENOM(255) 
INT ID(4) 
INT TITRE(1) 
ENDSEGMENT 

  • Cette instruction lit une table en Base et renseigne une séquence avec le résultat et la renvoie au client. Deux types de format de réponse sont possibles : Soap Xml et JSON. 
  • Chez nous, cette instruction est dans la Librairie SW2_LR et est cochée WebServices et Remote. 

N.B. : Prendre directement une where clause en paramètre est facile à mettre en œuvre mais très dangereux  car cela pose un problème d’injection SQL : la where clause peut être malicieuse et cachée un ordre SQL permettant la destruction de données ou la récupération de données interdites. 

Ce problème est d’autant plus sensible que dans le cadre d’un service REST, il n’est plus possible de contrôler la qualité et l’honnêteté de l’appelant. 

C’est pourquoi on a préféré utiliser 2 variables nom et prénom et utiliser des variables Hôtes qui ne permettent plus l’injection SQL.  

4.2) Génération
  • Dans option/Setup/Java sélectionner, choisir Servlet comme WebServices et cocher REST
  • Puis jBoss comme serveur et cocher Ear
  • Ensuite appuyez sur more et sélectionnez comme Application server Target Mode : Jakarta
  • Puis créez une configuration Serveur avec un Target Base de données
  • Ici on a choisi Oracle

N.B. il faut définir la même target sur le Serveur J2EE après avoir déployé le jar interface de la base de données : Voir l’annexe si besoin.

  • Ensuite, allez dans le menu Build/Build Resources.. et cochez Java Generator et Webservices 
  • Quand la génération se termine, vous obtiendrez une EAR de même nom que la config. Sous votre Priv/Test : Ici on obtient WS02.ear.
4.3) Déploiement sur Wildfly
  • Démarrez votre WildFly puis allez sur la page d’administration 
  • Appuyez sur start 
  • Puis sur l’onglet deployments, appuyez sur le  
  • Puis upload deployment 
  • Ensuite drag et drop (tirez et relâchez) de votre EAR

Vos services web sont maintenant déployés. 

4.4) Tests

Pour nos tests Soap, on utilise Soap-Ui. 

  • Pour l’instruction Seldemo4, activez la requête SELDEMO4 

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:sw2=”http://sw2_lr.webservices.natsys.fr/”> 
   <soapenv:Header/> 
   <soapenv:Body> 
      <sw2:SELDEMO4> 
         <!–Optional:–> 
         <szNOM>Tawil</szNOM> 
         <!–Optional:–> 
         <szPRENOM>Antoine</szPRENOM> 
      </sw2:SELDEMO4> 
   </soapenv:Body> 
</soapenv:Envelope> 

  • Et on obtient, la réponse :

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”> 
   <soap:Body> 
      <ns2:SELDEMO4Response xmlns:ns2=”http://sw2_lr.webservices.natsys.fr/”> 
         <LASEQ> 
            <list> 
               <ID>1</ID> 
               <NOM>Tawil</NOM> 
 <PRENOM>Antoine</PRENOM> 
               <TITRE>0</TITRE> 
            </list> 
         </LASEQ> 
    </ns2:SELDEMO4Response> 
   </soap:Body> 
</soap:Envelope> 

  • Pour obtenir la réponse JSON, cochez au préalable la checkbox REST vue plutôt, puis utilisez un navigateur ou tout simplement Curl avec l’URL suivante :

localhost:8080/SW2_LR_jaxwsn/rest/invoke/SELDEMO4?szNOM=Tawil&szPRENOM=Antoine
(SW2_LR étant le nom de la librairie NatStar auquel on rajoute _jaxwsn) 

  • Et on obtient alors la réponse suivante :

{
“responseFormat”: 802, 
    “response”: { 
        “serviceName”: “sw2_lr.SELDEMO4”, 
        “outputParameters”: [            {                “LASEQ”: [                    { 
                        “class”: “fr.natsys.webservices.sw2_lr.THESEGBean”, 
                        “attributes”: [ 
                            {   “ID”: 1  }, 
                            {   “NOM”: “Tawil”                }, 
                            {    “PRENOM”: “Antoine”   }, 
                            {       “TITRE”: 0                      } 
                        ]  }    ]    }    ]   }} 

N.B. : Ce format de réponse peut être utilisé directement à partir d’Angular ou React.

4.5) Annexe

Déploiement de la connexion Base de données 

Depuis la page d’administration de WildeFly, appuyez :

  • sur start,
  • Puis sur l’onglet deployments, appuyez sur le +
  • Puis upload deployment
  • On commence par la ojdbc11.jar (la plus récente lors de la rédaction)
  • Puis next … puis Finish
  • Puis configuration/datasources et drivers/datasources puis add datasource
  • Oracle puis next

La JNDI Datasource de la config NatStar doit correspondre à la partie après java:/datasources/ du JNDI Name de la config du datasource du Wildfly. Ici oracleDS

  • Puis Driver name l’ojdbc installé
  • puis l’url de la base comme celle de NatStar
  • Puis test connexion puis Finish

Pour plus de précisions sur les autres possibilités des services web, contactez la formation Services Web de Nat System par téléphone au 01 45 14 73 73 ou par mail au service-gestion@natsystem.fr

Vous souhaitez avoir plus de renseignements sur nos produits ou nos offres ?