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

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

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

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

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

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

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

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

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