API ... Кой изгражда APUI?

работен поток1

Имаме интерфейси за програмиране на приложения от доста време в индустрията. Предизвикателството на an API намира ресурсите за развитие, необходими за програмиране на интеграцията. Не е лесно. Използвайки всеки съвременен език за програмиране, обикновено се изисква да публикувате променливи в услуга и след това да извличате резултатите с помощта на XML (eXtensible Markup Language).

През 2000 г. работех за консултантска дейност по маркетинг на бази данни в Денвър, Колорадо и имахме инструмент, наречен Sagent Solutions. В крайна сметка Sagent е закупен от Group1. Group1 е добре позната в маркетинговата сцена за бази данни за създаване на фантастични приложения. Не съм сигурен какво се случи с продуктите на Sagent, които използвах, но те бяха невероятни. В лявата част на екрана имахте „трансформации“ и можете да ги плъзнете в работен поток. Всички входове и изходи на всяка трансформация автоматично ще се свържат със следващата трансформация.

Така че, бих могъл да изградя работен поток за импортиране на файл, картографиране на полетата в база данни, трансформиране на стойностите на полетата, изчистване на адресите, геокодиране на адресите, експортиране на завършения файл и т.н. Мога дори да разделя работния процес и да направя няколко процеси със същите данни. При прегледа на „back-end“ на работен поток, Sagent всъщност съхранява плана, използвайки XML. Това основно означава, че ако искате, можете динамично да изграждате и изпълнявате работен поток. Решението беше 6 -цифрено решение, но изграждането на план за манипулиране на хранилище на данни отне минути, а не дни.

С появата на API, уеб услуги, SOAP, Flex, Ajax и т.н ... Любопитен съм защо никой все още не е създал уеб-базиран потребителски интерфейс за програмиране на приложения. С други думи, интерфейс за плъзгане и пускане за API обаждания. С SOAP компаниите съхраняват WSDL (език за дефиниция на уеб услуги), който в основата си е програмна енциклопедия за това как да се използва уеб услугата. За пет години никой не е успял да разработи решение за тълкуване на API или уеб услуга за визуално изграждане на работен процес? Някой работи ли по това?

Ето моята идея от 1 милиард долара за деня. Ако някой може да изгради интерфейс Flex, който може да чете WSDL и визуално да представя обажданията, тогава можете да плъзнете и пуснете взаимодействията между повикванията. Това е липсващата връзка на мрежата ... прави мрежата достъпна за всеки, за да „програмира“ своето собствено решение, без да се налага да разбира езици.

Какво мислите?

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.