API… Qui construit un APUI?

flux de travail1

Nous avons des interfaces de programmation d'applications depuis un certain temps dans l'industrie. Le défi d'un API trouve les ressources de développement nécessaires pour programmer l'intégration. Ce n'est pas facile. En utilisant n'importe quel langage de programmation moderne, vous devez généralement publier des variables sur un service, puis récupérer les résultats en utilisant XML (eXtensible Markup Language).

En 2000, je travaillais pour un cabinet de conseil en marketing de base de données à Denver, Colorado et nous avions un outil appelé Sagent Solutions. Sagent a finalement été acheté par Group1. Group1 est bien connu dans le domaine du marketing de base de données pour créer des applications fantastiques. Je ne sais pas ce qui est arrivé aux produits Sagent que j'utilisais, mais ils étaient incroyables. Sur le côté gauche de votre écran, vous aviez des «transformations» et vous pouviez les faire glisser dans un flux de travail. Toutes les entrées et sorties de chaque transformation seraient automatiquement liées à la transformation suivante.

Ainsi, je pourrais créer un workflow pour importer un fichier, mapper les champs dans une base de données, transformer les valeurs des champs, nettoyer les adresses, géocoder les adresses, exporter le fichier terminé, etc. Je pourrais même diviser le workflow et faire plusieurs traite avec les mêmes données. En examinant le «back-end» d'un workflow, Sagent a en fait stocké le plan en utilisant XML. Cela signifie essentiellement que vous pouvez créer et exécuter dynamiquement un flux de travail si vous le souhaitez. La solution était une solution à 6 chiffres, mais la construction d'un plan pour manipuler un entrepôt de données prenait quelques minutes au lieu de jours.

Avec l'avènement des API, des services Web, SOAP, Flex, Ajax, etc. Je suis curieux de savoir pourquoi personne n'a encore construit une interface utilisateur de programmation d'applications basée sur le Web. En d'autres termes, une interface glisser-déposer pour API appels. Avec SOAP, les entreprises stockent un WSDL (Web Service Definition Language) qui est essentiellement une encyclopédie programmatique expliquant comment consommer le service Web. En cinq ans, personne n'a pu développer une solution pour interpréter un API ou Web Service pour créer visuellement un workflow? Quelqu'un travaille-t-il là-dessus?

Voici mon idée d'un milliard de dollars pour la journée. Si quelqu'un pouvait créer une interface Flex capable de lire un WSDL et de représenter visuellement les appels, vous pouvez alors faire glisser et déposer les interactions entre les appels. C'est le chaînon manquant du Web… rendre le Web accessible à tous pour «programmer» sa propre solution sans avoir à comprendre aucune langue.

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..