De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ?
-------------------------------------------------
Table des matières * Introduction * Le développement de protocoles applicatifs * Choisir SOAP ? * REST * Un style d’architecture * Architectures orientées ressource * Une interface simple et uniforme * REST et les web services ? * Des services web REST * Pour en finir avec les API REST * Passer d’un modèle à l’autre * Les avantages de la démarche * Conclusion * Bibliographie
-------------------------------------------------
Introduction
De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ?
Nous parlons ici de mettre en place un protocole applicatif sur le web pour échanger de l’information avec un grand nombre de clients. Une erreur de conception ou une faille de sécurité engendreraient des coûts exhorbitants si elles devaient être corrigées. C’est une différence importante avec la problématique des EAI (Enterprise Application Integration). Une erreur de conception sur une architecture