Que les choses soient claires : j'ai été un early adopter de SOAP. Dès 2000 j'ai été l'auteur d'une librairie écrite en C++ et Java qui implémentait SOAP (ref). Ce protocole était à l'époque une proposition assez bien accueillie par la communauté des développeurs. Mais force est de constater que les défauts de SOAP n'ont jamais été corrigés, et que l'usage généralisé de ce standard de facto n'a pas permis d'améliorer les propositions.
Qui en effet saurait dire ce qu'est une SOAPAction ? Quelle différence avec l'URL ou la méthode ? Comment expliquer qu'on ne saura pas dire quel service est réellement invoqué en ne regardant que l'URL ? Que peut contenir réellement l'entête ? etc. Je laisse les adeptes de la génération automatique (et opaque) répondre que tout ceci est inutile car les générateurs de code font tout à notre place... heureusement d'ailleurs. Mais pour ceux que le fonctionnement intéresse, au-delà du générateur opaque, point de salut, sauf à limiter l'usage de SOAP et revenir à des échanges plus simples mais tout aussi inter-opérables et orientés web services : REST.
C'est l'objet de propos tenus récemment à "Paris On Rails" (d'où l'écriture soudaine de ce message).
Cela fait longtemps que je prône moi-même l'usage de l'architecture de Mr Fielding, j'en ai même fait un petit [micro?] framework Open Source : REST-art.
Aucun commentaire:
Enregistrer un commentaire