La méthode est au moins aussi vieille que le composant XMLHttpRequest, donc date de bien avant les années 2000, on utilisait cette méthode pour transmettre données et traitements, du serveur vers le client (et vice versa) et ce, de manière transparente, …. du AJAX quoi !

Sauf que la méthode ne se base pas sur un format XML ( aujourd’hui classique pour ce type d’architecture ) pour les échanges de données, mais sur un code interprétable directement par le client à son arrivée, qui vous met à disposition des objets, tableaux, fonctions et procédures utilisables instantanément !

La méthode est idéale à mes yeux pour un échange client serveur transparent (AJAX) pour certaines opérations simples (comme le chargement dynamique de listes, de combos, modification de l’interface etc..), car il n’oblige pas l’utilisation de composants XMLhttp… ni de parser XML dont on connaît les performances (pas de problème avec le temps CPU disponible sur le client, par contre, au niveau serveur nous n’avons pas la même disponibilité.) et permet en plus des données, de transmettre du code interprétable directement !

JSON a le mérite de vouloir encadrer la méthode, par son formalisme et ses interfaces disponibles pour l’utiliser avec un maximum de languages de programmation : ActionScript,C,C++,C#,Cold Fusion,Delphi,E,Erlang,Java,JavaScript,Lisp,Lua,ML and Ruby,Objective CAML,OpenLaszlo,Perl,PHP,Python,Rebol,Ruby,Squeak…
Le seul reproche que l’on pourrait faire à JSON, c’est de ne pas pouvoir transmettre du code de traitement (fonctions et precédures…).

• JSON – http://www.json.org/

Incroyable, hier j’ai fait une présentation à une maîtrise d’oeuvre (chef de projet et devs) des principes de AJAX, sans jamais prononcer les mots AJAX, WebDeuxPointZéro etc…..

Juste présenté les avantages, les possibilités et surtout une solution à un problème technique auquel les devs n’avaient pas de solutions.

En fait la boîte pour qui je travaille est tellement réticente à travailler avec des nouvelles technologies (on peut comprendre, quand on voit la qualité des productions du service, on ne prend pas de risques…..) que je me préparais à des retours du type, « Il faut quantifier le besoin, les outils », « Etudes d’impact », »Etudes de faisabilité », « Homologation de la technologie…. », « Méthodologie…. » (ça c’est les CDP qui en fait n’ont rien compris ou qui veulent du budget) et des réflexions protectionnistes de la part des Devs … rien de tout ça, en fait la solution présentée apparaissait tellement simple et innovante sans être révolutionnaire, parce qu’elle s’appuyait sur des technos connues … (Javascript, Woaaa !), qu’elle a été immédiatement codée et l?on me demande maintenant un petit document en support pour les équipes.

En fait, le Web2.0, AJAX (ça désigne quoi, des requêtes transparentes ?) ce sont plutôt des termes obscurs pour les esprits précis et cartésiens qui caractérisent les informaticiens (les vrais, pas ceux qui utilisent Word ou qui essayent de cliquer plus vite que leurs voisins…).

Je me demande quel accueil la solution aurait reçu si j’avais prononcé ces mots un peu trop nuageux.

Attention, je ne remet pas en cause le Web2.0 ou les nouveaux usages du web qui apparaissent ici et la, la plupart du temps en beta; je vous livre une expérience… )

Au passage, je suis passé pour un gourou… lol, dans l’obscurité une étincelle peut vous paraître plus aveuglante qu’un soleil en pleine nuit (le jour quoi).