API ... Quen está a construír un APUI?

fluxo de traballo1

Temos interfaces de programación de aplicacións durante bastante tempo na industria. O reto dun API está a atopar os recursos de desenvolvemento necesarios para programar a integración. Non é doado. Empregando calquera linguaxe de programación moderna, normalmente está obrigado a publicar variables nun servizo e despois recuperar os resultados empregando XML (eXtensible Markup Language).

No 2000, traballaba para unha consultoría de mercadotecnia en bases de datos en Denver, Colorado e tiñamos unha ferramenta chamada Sagent Solutions. Sagent foi finalmente comprado por Grupo 1. Group1 é ben coñecido na escena de mercadotecnia de bases de datos por crear algunhas fantásticas aplicacións. Non estou seguro do que pasou cos produtos Sagent que adoitaba usar, pero foron incribles. Na parte esquerda da pantalla tiña "transformacións" e podería arrastralas a un fluxo de traballo. Todas as entradas e saídas de cada transformación vincularíanse automaticamente á seguinte transformación.

Así, podería crear un fluxo de traballo para importar un ficheiro, mapear os campos nunha base de datos, transformar os valores dos campos, limpar os enderezos, xeocodificar os enderezos, exportar o ficheiro completado, etc. Incluso podería dividir o fluxo de traballo e facer varios procesos cos mesmos datos. Ao revisar o "back-end" dun fluxo de traballo, Sagent realmente almacenou o plan utilizando XML. Isto basicamente significa que se podería construír e executar dinámicamente un fluxo de traballo se o desexa. A solución era unha solución de 6 díxitos, pero a creación dun plan para manipular un almacén de datos tardou minutos en vez de días.

Coa chegada das API, servizos web, SOAP, Flex, Ajax, etc ... Estou curioso por que ninguén aínda ten que construír unha interface de usuario de programación de aplicacións baseada na web. Noutras palabras, unha interface de arrastrar e soltar para API chamadas. Con SOAP, as empresas almacenan un WSDL (linguaxe de definición de servizos web) que é basicamente unha enciclopedia programática sobre como consumir o servizo web. En cinco anos ninguén foi capaz de desenvolver unha solución para interpretar un API ou servizo web para crear visualmente un fluxo de traballo? Alguén está traballando niso?

Aquí está a miña idea de $ 1 billón para o día. Se alguén puidese construír unha interface Flex que poida ler un WSDL e representar visualmente as chamadas, entón podería arrastrar e soltar as interaccións entre as chamadas. É a ligazón que falta da web ... facendo que a web sexa accesible a calquera para "programar" a súa propia solución sen ter que entender ningún idioma.

¿Que pensas?

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.