C'est peut-être plus productif à court terme, mais à long terme je pense que même sur du backoffice c'est un mauvais calcul.
L'exemple que je connais le mieux est le backoffice de AirFrance. Ils ont une architecture orientée service très complète et belle techniquement (bien qu'un peu lente), qui pourrait parfaitement exposer au web des belles API REST avec un peu de travail.
Actuellement ils ont des espèces de «choses» Java J2E qui font un gloubi-boulga entre plein de services et des interfaces HTML-IE6 développées de manière certes productives mais in-maintenables.
La logique des vues est totalement explosée entre le serveur et le client avec des états dans tout les sens, c'est quasiment impossible à tester efficacement et à faire évoluer sans repartir de zéro. Le problème, c'est que ces gloubi-boulga contiennent désormais beaucoup trop de logique métier pour pouvoir évoluer à faible coût.
Une séparation API REST/Web aurait imposé de créer la logique entre les services cotés serveur une bonne fois pour toute et simplifier le développement cotés client. Après c'est une façon de faire nouvelle et la plupart des applications concernées datent de la sombre époque PHP/MySQL/HTML/JavaScript dans un seul fichier.
[^] # Re: Our web development workflow is completely broken
Posté par dave_null . En réponse à la dépêche Brackets : l'éditeur du web, par le web, pour le web. Évalué à 4.
C'est peut-être plus productif à court terme, mais à long terme je pense que même sur du backoffice c'est un mauvais calcul.
L'exemple que je connais le mieux est le backoffice de AirFrance. Ils ont une architecture orientée service très complète et belle techniquement (bien qu'un peu lente), qui pourrait parfaitement exposer au web des belles API REST avec un peu de travail.
Actuellement ils ont des espèces de «choses» Java J2E qui font un gloubi-boulga entre plein de services et des interfaces HTML-IE6 développées de manière certes productives mais in-maintenables.
La logique des vues est totalement explosée entre le serveur et le client avec des états dans tout les sens, c'est quasiment impossible à tester efficacement et à faire évoluer sans repartir de zéro. Le problème, c'est que ces gloubi-boulga contiennent désormais beaucoup trop de logique métier pour pouvoir évoluer à faible coût.
Une séparation API REST/Web aurait imposé de créer la logique entre les services cotés serveur une bonne fois pour toute et simplifier le développement cotés client. Après c'est une façon de faire nouvelle et la plupart des applications concernées datent de la sombre époque PHP/MySQL/HTML/JavaScript dans un seul fichier.