API… ¿Quién está construyendo una APUI?

flujo de trabajo1

Hemos tenido interfaces de programación de aplicaciones durante bastante tiempo en la industria. El desafío de un API es encontrar los recursos de desarrollo necesarios para programar la integración. No es fácil. Al utilizar cualquier lenguaje de programación moderno, generalmente se le solicita que publique variables en un servicio y luego recupere los resultados utilizando XML (eXtensible Markup Language).

En 2000, estaba trabajando para una consultoría de marketing de bases de datos en Denver, Colorado y teníamos una herramienta llamada Sagent Solutions. Sagent finalmente fue comprado por Group1. Group1 es bien conocido en la escena del marketing de bases de datos por crear algunas aplicaciones fantásticas. No estoy seguro de qué pasó con los productos Sagent que solía usar, pero eran increíbles. En el lado izquierdo de la pantalla tenía 'transformaciones' y podía arrastrarlas a un flujo de trabajo. Todas las entradas y salidas de cada transformación se vincularían automáticamente a la siguiente transformación.

Entonces, podría construir un flujo de trabajo para importar un archivo, mapear los campos en una base de datos, transformar los valores de los campos, limpiar las direcciones, geocodificar las direcciones, exportar el archivo completo, etc. Incluso podría dividir el flujo de trabajo y hacer múltiples procesos con los mismos datos. Al revisar el "back-end" de un flujo de trabajo, Sagent realmente almacenó el plan utilizando XML. Básicamente, eso significa que puede crear y ejecutar dinámicamente un flujo de trabajo si lo desea. La solución fue una solución de 6 dígitos, pero crear un plan para manipular un almacén de datos tomó minutos en lugar de días.

Con la llegada de las API, los servicios web, SOAP, Flex, Ajax, etc. Tengo curiosidad por saber por qué nadie ha creado todavía una interfaz de usuario de programación de aplicaciones basada en la web. En otras palabras, una interfaz de arrastrar y soltar para API llamadas. Con SOAP, las empresas almacenan un WSDL (Web Service Definition Language) que es básicamente una enciclopedia programática sobre cómo consumir el servicio web. En cinco años nadie ha podido desarrollar una solución para interpretar un API o servicio web para crear visualmente un flujo de trabajo? ¿Alguien está trabajando en eso?

Aquí está mi idea de mil millones de dólares para el día. Si alguien pudiera construir una interfaz Flex que pueda leer un WSDL y representar visualmente las llamadas, entonces podría arrastrar y soltar las interacciones entre las llamadas. Es el eslabón perdido de la web ... hacer que la web sea accesible para que cualquiera pueda "programar" su propia solución sin tener que entender ningún idioma.

¿Qué piensas?

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.