tyPouypOblOg

J’ai lu il y a quelques jours un billet de Jean-François Helie: REST ou SOAP . J’aimerais ajouter ici mon petit piment, ma petite reflexion sur ces deux mode de communication.

Pour ce qui ne le savent pas encore, REST est une architecture basé sur ce qui fait le web: URI , HTTP et un concept d’object, ou plutôt de ressources bien pensé. C’est une architecture légère et relativement facile à mettre en place. Elle est de plus très ouverte et simple à utiliser.

Quant à SOAP, c’est un protocole de communication très utilisé (le seul?) dans la construction d’architecture de type SOA. Basé sur XML. Très verbeux, il est souvent opposé à REST (mêms si c’est plutôt la SOA qui s’oppose à REST).

Je rejoint Jean-François sur le fait que finalement, selon ce que nous voulons mettre en place, l’une ou l’autre des solutions s’adapte mieux. Mais j’ajouterais que pour moi, SOAP est interessant dans une architecture où les échanges sont asynchrone. Effectivement, REST, basé sur le protocole HTTP, donne une réponse immédiate. SOAP peut-être utilisé comme tel, mais finalement, SOAP utilisé sur le protocole HTTP, ça faut un peu double emploi: Une enveloppe dans une enveloppe. SOAP dans une utilisation asynchrone prend du sens. Utilisé sur un protocole spécifique (beurk ! je préfère les formats ouverts !) ou bien du type smtp/imap/pop cela devient légitime.

Donc pour moi, outre l’aspect gestion de sécurité (il me semble qu’avec une architecture REST, il existe des solutions pour la gestion de la sécurité), le choix entre l’utilisation de REST et l’utilisation de SOAP, c’est plutôt une question de timing :-)

Je cherche depuis quelque temps à constituer mon carnet d’adresse dans un format portable,ouvert comme il faut quoi.

La démarche normale serais de placer un serveur LDAP sur la bricabox. Mais LDAP, bien qu’énormément utilisé ne me semble pas convenir à mes souhait, ou peut-être est-ce parce que je ne suit pas assez familiarisé avec l’engin. Ou peut-être me manque-t-il un bon client fait pour administrer mon carnet. L’utiliser, ça c’est facile, tout les client mail peuvent se brancher sur un LDAP. Et pour ce qui est de l’authentification, c’est pareil, on trouve des tutoriaux pour chacun d’entre eux, ou presque.

Etant un petit fan d’XML, je suis un peu les discussions autour du WebSemantic également. Et j’avais noté l’existance de FOAF (FOAF sur wikipedia). C’est un vocabulaire “RDF(Ressource Description Framework” (RDF sur wikipedia) pour décrire des personnes et leurs relation. Interessant. Mais finalement cela me posait un problème: la mise à disposition de certaines informations personnel. Pour les adresse email il y a apparemment un mécanisme basé sur un hashage qui permet de masquer les adresse email. Mais rien n’empêcherais quelqu’un de faire un mauvais usage de simples noms.

Et a force de fouiller sur le sujet, je suis tombé sur une présentation en PDF de Mr Sebastian Dietzold dont je met à disposition une copie chez moi: Accessing RDF Knowledge bases via LDAP clients (Si ça pose un soucis je l’enleverrais). Et la je voie du LDAP ET du FOAF (en fait du RDF plutôt mais bon).

Du coup je suis paumé dans ma reflexion. Je ne sais pas trop quoi penser de tout ça. Je devrais surement poser un peu mes idées sur papier, et ensuite seulement chercher un outil qui covienne (voir en modifier un s’il le faut).

Et vous vous faites comment ? Un fichier csv tout moisi et pas à jour ? Un carnet papier ?

edit: Et voilà qu’en continuant mes recherches d’infos sur le sujet, je tombe sur un post-it du forum d’alsacreations rédigé par Raphaël Goetter : Qu’est-ce que FOAF On y apprend qu’il y a une mutinerie… Ou plutôt que quelque grand monsieur du web n’apprecie pas trop la compléxité de Foaf et on créé XFN… Mais la critique constructive de Karl Dubost a coupé cours mes envies d’investigation dans ce nouveau venu. Il fallait cependant que je vous tienne au courant :-p

Les utilisateurs d’OpenBSD le savent déjà surement, le set xbase est nécessaire, même pour une installation serveur (enfin presque).

Effectivement, lors du passage à la version 4.2, le set graphique est passé d’un xorg à xenocara un serveur X basé sur xorg 7.2, revu et corrigé à la sauce Open. Du cout, la lib expat utilisé est celle de xenocara. Manque de bol (ou pas) expat est utilisé par beaucoup de paquet (comme vim par exemple) et du coup, pour une simple installation serveur il faut installer xbase (qui contient la lib expat).

C’est bien la première fois que je suis déçu par OpenBSD… Quel dommage d’avoir raté ça. Mais comme il est dit sur @misc (la mailling list principal d’OpenBSD) plus que 5 mois a attendre pour la version 4.3.

Effectivement, dans cette version, la lib expat est rappatrié dans le set base :-)

Alors, petit accro, mais rapidement corrigé.

Qui aurais pensé à ça ? l'apparition de la methode XmlHTTPRequest, disponible uniquement sur IE ? Pas grand monde sur le coup.

Plusieurs personne toutefois on commencé ) en voir l'interêt et s'en servir, discretement. Je me souviens dans ma société de services à l'époque, nous débutions dans les interfaces Web. Marre de refaire tout le temps la même chose, du coup nous avions entrepris de developper un "framework" javascript. Au moment de décider d'un mode de communication avec le serveur, nous avions choisi d'utiliser cette methode dont personne n'osais parler à l'époque. Nous nous demendions si c'etais le bon choix. L'explosion des solutions à base de génération de page coté serveur nous faisais pensé que nous avions tord

Et finalement... Maintenant un site qui n'utilise pas la combo Xml Javascript n'est plus dedans, n'est pas "Web 2.0". La honte.

Le nombre de service basé sur cette technologie est impressionnant à en croire cette liste fourni sur www.econsultant.com. Un groupe de travail c'est même formé autour de ce Buzz: web20workgroup.

Et pourtant, comme à l'époque avec mes collègues, je n'arrive pas à me dire que c'est la meilleur solution. Le web n'a pas été créé sur ce modèle, mais plutôt pour passer d'un document à un autre. Alors faut-il être contre le progrès ?

Peut-être que ce qui me dérange c'est que souvent tout ceci est fait au détriment de l'accessibilité ... A en croire ces recommandations [www.w3.org] ce n'est pas le tout AJAX qu'il faut faire. De même qu'en lisant ce livre blanc de l'accessibilite je me demande si gmail , traitement de texte web et autres, sont utilisable via lynx... A voir.

De mon coté je souhaite l'accessibilité, il faut d'ailleurs que je me penche très sérieusement sur mon site, qui est, pour le moment, propulsé par typo, pour vérifier sont accessibilité.
Grand utilisateur de javascript à une époque, j'ai des remorts à m'en servir maintenant. Même pour des application intranet qui pourtant sont souvent effectué en obligeant les gens à utiliser tel ou tel navigateur, tel version. Mais ceci n'empèche-t-il pas l'intégration dans l'entreprise de personnes ayant un handicap ? Pourquoi une personne mal-voyante ne pourrait-elle pas bénéficier des même outils que les autres ?

Bref, je sais pas si c'est le printemps, mais en ce moment je remonte tout ces débats du fond de ma mémoire, en espérant trouver cette fois une ébauche d'idée de solution. En attendant, je vais aller faire à contre coeur de l'ajax dans mon application intranet...