« REST » un peu pour voir mon « SAOP »

Lors d’un de mes précédents comité (de gentils) utilisateurs  je découvrais (avec surprise) que beaucoup d’applications cibles de mon services étaient réfractaires à l’utilisation de Webservices.

Pour trois principales raisons :

–  Soit par manque de compétence  dans l’intégration d’un Webservices dans une application (que ce soit en matière de développement, de capacité à interpréter le token, ou de simple notion de sécurité)
Ce qui en soit est à la fois une bonne et une mauvaise raison, car les développeurs de Webservices mettent souvent à dispositions des potentiels utilisateurs des « how to » pour l’intégration de leur WebServices  et qu’à force de passer par des solutions de contournements qui sur la durée se révèlent à fort coût de maintenance parce qu’on n’a pas voulu investir dans la formation d’un développeur c’est quand même un peu ballot de se rentre compte qu’intégrer un WebServices c’est tout de même pas si compliqué.

– Soit parce que leur appli (progiciel ou développement interne !!!) possède déjà une solution de contournement pré-intégrée et qu’ils ne voient pas pourquoi ils se rattacheraient à un WebServices alors « qu’on a déjà de quoi faire ».
Ce qui quelque part, tient debout (fièrement, avec les poings sur les hanches même que), même si tout ce qui est pré-developpé, à moins d’être facile à maintenir, est quand même une marque de rigidité qui n’est pas ce qui est le plus connu dans le WebServices.

– Soit parce que leur progiciel n’a pas d’interface Webservices (ou, si peut-être mais elle est cachée, ils l’ont pas vu, ou ils l’ont rangé là bas derrière, parce que ça fait super peur un Webservices quoi ! faut pas la montrer à tout le monde, c’est comme un port USB, c’est intime…)
A moins que l’éditeur du logiciel vous garantisse qu’il ne possède pas d’interface Webservices, et qu’il n’en possèdera jamais (et là, bon, autant de résistance au changement de la part d’un éditeur, je vous conseil d’en changer) cette excuse ci est somme toute, honorable, mais à fort potentiel de « mouais » pas super convaincus.

Mais le client est roi. Donc on ne discute pas ce que le client veut. (Cela dit, il me semble qu’en tant qu’opérationnel, fonctionnel, ou institutionnel de SI, on est de toute manière dans une position de consultant et de conseiller quant à la meilleure façon de brancher ton truc, là, oui, dans le trou-trou là, ici, là, et que bon, si on a les compétences pour mettre à disposition un Webservices, normalement, on sait comment s’y connecter, ne serait-ce parce qu’on l’a déjà testé le bouzin avant que de vous le présenter, donc au pire, on peut vous l’apprendre… Ma gueule ? Oui bon ok, ma gueule. )

En conclusion, les Webservices c’est bon mangez-en.

Enfin pour faire plus sérieux, Pratiquer le Webservices, c’est tout de même répondre à deux définitions de l’économie de services :

– La prestation extérieure, qui évite de payer des gens à maintenir des applications qui ne seront pas amenées à bouger beaucoup dans leur structure, mais qui rendront longtemps le même service avec la même garantie de format en entrée comme en sortie, (oui vous me direz ça, y’a pas que le WebServices pour le faire… mais c’est quand même le principe), le tout pouvant être utilisé par un « simple » protocole HTTP et piloté par votre appli.

– La possibilité de faire de l’orchestration de multiples services en temps réel, sur lesquels on n’a pas de prise (lesquels on ne veut pas avoir à gérer) mais avec qui on souhaite opérer, ce qui en terme de processus métier (le dernier truc à la mode de la gestion de projet très très itil) est quand même la solution la plus simple. (oui on peut toujours faire plus compliqué, c’est plus long, c’est plus cher, et ça brille, mais c’est plus compliqué…)

– Oui j’ai rajouté un 3ième point, ça n’est pas une erreur, c’est une extension ; C’était pour aborder le fait que souvent, quand on parle de Webservices, on parle de XML, souvent mais pas exclusivement, vous ne serez pas en « REST » (ou quoi que, en fait si) si vous n’aimez pas les « SOAP » opérations, parce que si derrière le XML se cache de barbares modules de « parsing » (berk c’est quoi un parseur ?) les solutions de Webservice offrent un large panel de choix dans les types et formats de sorties et d’entrée qui peuvent vous dispenser de XML…

En résumé :

Il existe un très large panel de Webservices et de formats associés, et il y a toujours un moyen de l’interfacer avec votre appli pour peu que quelqu’un mette un peu les mains dans le cambouis au moins une fois.
PS : Cet article s’est voulu volontairement avec sa volonté propre et de son plein gré (si si ! il atteste) accessible à des non-initiés comme à des initiés, toutefois,

– s’il ne vous était pas assez accessible, je vous invite à me contacter, je dois encore pouvoir faire plus simple.
– S’il était trop accessible, les pierres sont là, moi je suis là , vous savez ce qu’il vous reste à faire, et c’est aussi simple que d’appeler un Webservice.

Laisser un commentaire