API ... من يقوم ببناء APUI؟
لدينا واجهات برمجة التطبيقات لفترة طويلة في الصناعة. التحدي المتمثل في API هو إيجاد موارد التطوير اللازمة لبرمجة التكامل. انها ليست سهلة. باستخدام أي لغة برمجة حديثة ، يُطلب منك عادةً ترحيل المتغيرات إلى خدمة ما ثم استرداد النتائج باستخدام XML (لغة التوصيف القابلة للتمديد).
في عام 2000 ، كنت أعمل في شركة استشارية لتسويق قواعد البيانات في دنفر بولاية كولورادو وكان لدينا أداة تسمى حلول Sagent. تم شراء Sagent في النهاية بواسطة Group1. Group1 معروفة جيدًا في مشهد تسويق قواعد البيانات لبناء بعض التطبيقات الرائعة. لست متأكدًا مما حدث لمنتجات Sagent التي اعتدت استخدامها ، لكنها كانت رائعة. على الجانب الأيسر من شاشتك ، كان لديك "تحويلات" ويمكنك سحبها إلى سير عمل. سيتم ربط جميع مدخلات ومخرجات كل تحويل تلقائيًا بالتحويل التالي.
لذلك ، يمكنني إنشاء سير عمل لاستيراد ملف ، وتعيين الحقول في قاعدة بيانات ، وتحويل قيم الحقول ، وتنظيف العناوين ، وترميز العناوين جغرافيًا ، وتصدير الملف المكتمل ، وما إلى ذلك ، حتى أنني يمكنني تقسيم سير العمل والقيام بعدة بنفس البيانات. عند مراجعة "النهاية الخلفية" لسير العمل ، قام Sagent بالفعل بتخزين الخطة باستخدام XML. هذا يعني في الأساس أنه يمكنك إنشاء سير عمل وتنفيذه ديناميكيًا إذا أردت ذلك. كان الحل عبارة عن حل مكون من 6 أرقام ، لكن بناء خطة للتعامل مع مستودع البيانات استغرق دقائق بدلاً من أيام.
مع ظهور واجهات برمجة التطبيقات ، وخدمات الويب ، و SOAP ، و Flex ، و Ajax ، وما إلى ذلك ... أشعر بالفضول لماذا لم يقم أحد بعد ببناء واجهة مستخدم لبرمجة التطبيقات على شبكة الإنترنت. بمعنى آخر ، واجهة السحب والإفلات لـ API المكالمات. باستخدام SOAP ، تقوم الشركات بتخزين WSDL (لغة تعريف خدمة الويب) التي تعد في الأساس موسوعة برمجية لكيفية استهلاك خدمة الويب. في غضون خمس سنوات ، لم يتمكن أحد من تطوير حل لتفسير API أو خدمة الويب لبناء سير عمل بشكل مرئي؟ هل هناك من يعمل على ذلك؟
ها هي فكرتي المليار دولار لهذا اليوم. إذا كان بإمكان شخص ما إنشاء واجهة مرنة يمكنها قراءة WSDL وتمثيل المكالمات بشكل مرئي ، فيمكنك سحب التفاعلات بين المكالمات وإفلاتها. إنه الرابط المفقود للويب ... جعل الويب متاحًا لأي شخص "لبرمجة" الحل الخاص به دون الحاجة إلى فهم أي لغة.
