API… Kto tworzy APUI?

przepływ pracy 1

Od dłuższego czasu mamy w branży interfejsy programowania aplikacji. Wyzwanie API jest znalezienie zasobów rozwojowych potrzebnych do zaprogramowania integracji. To nie jest łatwe. Korzystając z dowolnego nowoczesnego języka programowania, zwykle wymagane jest publikowanie zmiennych w usłudze, a następnie pobieranie wyników za pomocą XML (eXtensible Markup Language).

W 2000 roku pracowałem dla firmy konsultingowej ds. Marketingu baz danych w Denver w stanie Kolorado i mieliśmy narzędzie o nazwie Sagent Solutions. Sagent został ostatecznie zakupiony przez Group1. Group1 jest dobrze znana na scenie marketingu baz danych z tworzenia fantastycznych aplikacji. Nie jestem pewien, co się stało z produktami Sagent, których używałem, ale były niesamowite. Po lewej stronie ekranu masz „transformacje” i możesz je przeciągnąć do przepływu pracy. Wszystkie dane wejściowe i wyjściowe każdej transformacji byłyby automatycznie powiązane z następną transformacją.

Mogłem więc zbudować przepływ pracy, aby zaimportować plik, zmapować pola do bazy danych, przekształcić wartości pól, wyczyścić adresy, geokodować adresy, wyeksportować ukończony plik itp. Mogłem nawet podzielić przepływ pracy i wykonać wiele procesy z tymi samymi danymi. Przeglądając „zaplecze” przepływu pracy, Sagent faktycznie przechowywał plan wykorzystując XML. Zasadniczo oznacza to, że możesz dynamicznie budować i wykonywać przepływ pracy, jeśli chcesz. Rozwiązanie było rozwiązaniem 6-cyfrowym, ale zbudowanie planu manipulacji hurtownią danych zajęło kilka minut zamiast dni.

Wraz z pojawieniem się interfejsów API, usług sieci Web, SOAP, Flex, Ajax itp. Ciekaw jestem, dlaczego nikt jeszcze nie zbudował internetowego interfejsu użytkownika programowania aplikacji. Innymi słowy, interfejs przeciągnij i upuść dla API wezwania. Dzięki SOAP firmy przechowują WSDL (język definicji usług sieci Web), który jest w zasadzie programową encyklopedią opisującą sposób korzystania z usługi internetowej. W ciągu pięciu lat nikt nie był w stanie opracować rozwiązania umożliwiającego interpretację API lub usługa sieciowa, aby wizualnie zbudować przepływ pracy? Czy ktoś nad tym pracuje?

Oto mój pomysł na dzień za miliard dolarów. Jeśli ktoś mógłby zbudować interfejs Flex, który potrafi czytać WSDL i wizualnie przedstawiać wywołania, wtedy można przeciągać i upuszczać interakcje między wywołaniami. To brakujące ogniwo sieci… dzięki czemu sieć jest dostępna dla każdego, aby „zaprogramować” własne rozwiązanie bez konieczności rozumienia jakichkolwiek języków.

Co o tym myślisz?

Ta strona używa Akismet do redukcji spamu. Dowiedz się, jak przetwarzane są dane komentarza.