يجب القيام بالكثير من العمل لتنفيذ API. التخطيط المفرط يمكن أن يكون مضيعة للطاقة ، ونقصها يؤدي إلى عواقب وخيمة. في هذا الكتاب ، ستتلقى الحلول التي تسمح لك بتخصيص الموارد اللازمة وتحقيق المستوى المطلوب من الكفاءة في الوقت الأمثل. كيفية تحقيق التوازن بين المرونة والأداء مع الحفاظ على الموثوقية وسهولة التكوين؟ يشرح أربعة خبراء من أكاديمية API لمطوري البرامج ومديري المنتجات والمشاريع كيفية زيادة قيمة واجهات برمجة التطبيقات الخاصة بهم عن طريق إدارة الواجهات كمنتجات مستمرة.
تستند مواد الكتاب إلى معرفتنا الجماعية (مهدي مجوي ، إريك وايلد ، روني ميترا ، مايك أموندسن) على مدار سنوات عديدة من إنشاء وتطوير وتحسين واجهة برمجة التطبيقات - الخاصة بنا وغيرها. إنه يحدد كل خبرتنا. حددنا عاملين رئيسيين لتطوير واجهة برمجة التطبيقات الفعالة: الحاجة إلى نهج موجه نحو المنتج وتشكيل الفريق المناسب. لقد حددنا أيضًا ثلاثة عوامل مهمة لإدارة هذا العمل: القيادة وتطوير المنتجات وتطوير نظام API.
تشكل هذه العناصر الخمسة الأساس الذي يستند إليه برنامج إدارة API الناجح. نقدم للقارئ كل هذه المواضيع ونوفر إرشادات حول كيفية ملائمة هذه الموضوعات في سياق مؤسستك.
مقتطفات. أنظمة API
مع تزايد وظائف واجهة برمجة التطبيقات ، أصبح من المهم بشكل متزايد إدارة تطوير البرامج بحيث تزيد فوائد وقيمة مجموعة كاملة من واجهات برمجة التطبيقات للمؤسسة إلى الحد الأقصى. يجب أن تتذكر هذا الرصيد ، لأن أفضل طريقة (أو جيدة نسبيًا) لتوفير خدمة فردية باستخدام واجهة برمجة التطبيقات قد لا تكون مفيدة على الإطلاق إذا نظرت إليها من وجهة نظر سهولة استخدام هذه الخدمة كجزء من نظام مشترك.
تتزايد أنظمة واجهة برمجة التطبيقات الحديثة باستمرار من حيث إجمالي عدد واجهات برمجة التطبيقات ، فضلاً عن عدد واجهات برمجة التطبيقات التي تستخدمها الخدمات الجديدة. بالنظر إلى هذه الزيادة في الاعتمادات المتبادلة ، ندرك أنه سيكون من المفيد إذا لم يكن على مطوري الخدمات الجديدة فهم تصميمات API مختلفة تمامًا وتطبيقها. قد تكون الاختلافات مثيرة - على سبيل المثال ، ما إذا كانت واجهة برمجة التطبيقات تستخدم نمط REST أو نمطًا موجهًا للأحداث (راجع قسم التصميم في قسم التعريف بالأعمدة في الفصل 4) - ولكن حتى إذا كانت الأنماط متطابقة ، فيمكن اكتشاف اختلافات مثل استخدام تنسيق JSON أو XML.
من وجهة نظر مستخدم واجهة برمجة التطبيقات ، قد يكون من المفيد أيضًا استخدام مصطلحات مشتركة. على سبيل المثال ، إذا كنت تستخدم العديد من واجهات برمجة التطبيقات التي توفر بيانات المستخدم بأي شكل من الأشكال ، فسيكون من الأسهل إذا كان لديهم جميعهم نموذج مستخدم رئيسي واحد (حتى لو تم تقديمه بطريقة مختلفة قليلاً ، ومع ذلك ، من المفيد وجود نموذج مشترك للخدمات المختلفة) .
تشير فكرة فوائد التقييس بوضوح إلى أنه كلما كان ذلك أفضل. إلى حد ما ، ولكن في الوقت نفسه من المعروف أن التقييس يستغرق وقتًا وموارد ، فإنه عادةً لا يتطابق مع "النموذج الصحيح والأفضل فقط" ، ولكنه ببساطة يخلق نموذجًا يمكن للجميع أن يتوصلوا إليه بطريقة ما ، وبالتالي ، بشكل عام ، هذا الاستثمار له مخاطر ومزايا.
ربما لن يكون استخدام تنسيق فريد لكل واجهة برمجة التطبيقات هو الحل الأفضل ، فمن المنطقي أن تختار من بين التنسيقات الموجودة ، على سبيل المثال ، JSON أو XML. في هذه الحالة ، تفوق فوائد تطبيق المعايير الحالية الفوائد المحتملة للتنسيقات الفريدة. ومع ذلك ، قد يكون مكلفًا للغاية توحيد بعض عناصر الخدمات المختلفة ، على سبيل المثال ، نموذج المستخدم المذكور بالفعل. في هذه الحالة ، من المنطقي عدم الذهاب إلى مثل هذه النفقات غير المبررة من أجل العثور على نموذج المستخدم الحقيقي الوحيد والتوقف فقط عن طراز المجال.
بشكل عام ، من الناحية المثالية لكل خدمة ، لا نريد إعادة اختراع العجلة عندما لا يكون ذلك ضروريًا ، ولكن إعادة استخدام عناصر التصميم التي تقلل من تكلفة الموارد لإنشاء تصميم وفهمه وتنفيذه. إذا استطعنا تحقيق هذا المستوى المثالي من إعادة التطبيق ، أو على الأقل الاقتراب منه ، فسيسمح ذلك لمنشئي الخدمة بالتركيز على جوانب التصميم التي يجب التركيز عليها دون تشتيت الانتباه عن المشكلات التي تم حلها بالفعل.
نرى المزيد والمزيد من المنظمات تفعل ذلك تماما. ولكن الشيء الأكثر أهمية في هذا هو فهم وتأكد من أن أدلة المصممين يتم تحديثها باستمرار: يتم تقييم الأساليب الجديدة والموافقة عليها ، والطرق القديمة خرجت من التداول ، والقوة الدافعة الرئيسية وراء هذه التغييرات هي مجموعة من أساليب API المتطورة باستمرار في المنظمة.
من المهم أن نفهم أن نظام API هو بيئة متنقلة ومتغيرة باستمرار ، ولكي يستمر في العمل ، يجب أن تتبع الهندسة المعمارية نفس مسار التطوير المستمر. ثم يصبح مثل نظام واسع النطاق للغاية ، على سبيل المثال ، الإنترنت ، الذي ، من جهة ، يعمل طوال الوقت ، ومن ناحية أخرى ، يتغير باستمرار وتظهر فيه معايير وتقنيات جديدة باستمرار.
علم الآثار API
على الرغم من أننا نرى الآن عددًا كبيرًا من المؤسسات التي بدأت للتو في إنشاء برامج باستخدام واجهات برمجة التطبيقات ، فمن المهم أن نتذكر أنه في أي مؤسسة تستخدم تكنولوجيا المعلومات ، هناك بالتأكيد بعض واجهات برمجة التطبيقات التي تم استخدامها لفترة طويلة.
بناءً على التعريف ، واجهة برمجة التطبيقات هي أي واجهة تسمح لمكونين من البرنامج بالتفاعل. إذا قمت بتضييق التعريف إلى فهم حديث لواجهة برمجة التطبيقات الخاصة بالشبكة ، فهذه هي الواجهة التي تسمح لمكونين من البرامج بالتفاعل من خلال الشبكة.
في العديد من المؤسسات ، لا تُسمى هذه الواجهات واجهات برمجة التطبيقات (APIs) ولا يتم تصميمها لإعادة استخدامها (تذكر القصة المتعلقة بميثاق واجهة برمجة التطبيقات الشهيرة Jeff Bezos ، التي أخبرناها في قسم Bezos Charter التابع لقسم التفكير التصميمي في الفصل 3). ولكن في أغلب الأحيان توجد هذه الواجهات ، حتى إذا تم إنشاؤها واستخدامها للتكامل فقط للاستخدام الواحد (تقويض هذه إحدى الخصائص المفيدة الرئيسية لواجهة برمجة التطبيقات - إمكانية إعادة الاستخدام).
يمكن أن يكون العثور على تطبيقات proto-API وتطبيقها مفيدًا لأنه يوضح مكان ظهور الحاجة إلى التكامل (حتى إذا تم إنشاؤه باستخدام طرق لا تفي بأهداف API). لا يجب استبدال جميع واجهات برمجة التطبيقات APIs بواجهة برمجة تطبيقات تقليدية ، ولكن فقط بفهم التاريخ ، يمكنك الحصول على أفكار حول كيفية ملاحظة الحاجة إلى التكامل وما تم القيام به في هذا المجال وحيث قد تظهر الحاجة إلى تكامل إضافي.
API PROTO
توجد حاجة إلى تفاعل المكونات في جميع الأنظمة المعقدة التي تتكون من أجزاء منفصلة. واجهة برمجة التطبيقات هي إحدى طرق القيام بذلك ، ولكن هناك العديد من الطرق الأخرى. من وجهة نظر واجهة برمجة التطبيقات ، يمكن اعتبار أي آلية تستخدم لتفاعل المكونات التي ليست واجهة برمجة تطبيقات واجهة برمجة تطبيقات بروتو. في النظام المثالي ، باستخدام واجهة برمجة التطبيقات ، يتم تنفيذ جميع تفاعلات المكونات دون استثناء. إذا كنت تتذكر هذه الصورة المثالية ، فإن أي تفاعل بدون مساعدة من API يصبح مرشحًا للتحديث - ليتم استبداله بواجهة برمجة التطبيقات. لذلك ، يمكن اعتبار أي آلية لتفاعل المكونات دون مساعدة واجهة برمجة التطبيقات (API) بمثابة بروتوكول proto-API.
بشكل عام ، يمكن لعلم آثار واجهة برمجة التطبيقات مساعدتك على فهم نظام واجهة برمجة التطبيقات بشكل أفضل ، حتى إذا كان يتكون الآن من واجهات برمجة التطبيقات الأولية. إنه يوفر نقطة بداية لفهم الحاجة إلى التكامل التي نشأت في الماضي ، ولأية استثمارات في واجهة برمجة التطبيقات (API) يمكنك أفضل كشف شبكة إشكالية العديد من عمليات تكامل المستخدم. من خلال التجربة بمرور الوقت ، أصبح استبدال الدمج الذي تم إنشاؤه قبل ظهور واجهة برمجة التطبيقات (API) بالنماذج الحديثة أسهل من أي وقت مضى.
إدارة API على نطاق واسع
إدارة API على نطاق واسع هي فعل التوازن بين تقديم تصميم مشترك على مستوى النظام وزيادة حرية خيارات التصميم على مستوى واجهة برمجة التطبيقات الفردية. يعد الاختيار بين التكامل المركزي لتحقيق الاتساق والتحسين واللامركزية لتحقيق المرونة والتنمية مشكلة شائعة في نظام معقد.
- لقد أتاح لنا التكامل المركزي بنية تكنولوجيا المعلومات المؤسسية النموذجية في الماضي. كانت القوة الدافعة الرئيسية هي توحيد تنفيذ المهام من أجل توفيرها على النحو الأمثل وبأقل تكلفة. المستوى العالي من التكامل يبسط عملية التحسين حقًا ، لكن في الوقت نفسه يؤثر على القدرة على إجراء تغييرات وتطوير النظام النهائي.
- اللامركزية هي عكس ذلك. المثال الأكثر الوصول إليها وعلى نطاق واسع منه هو الإنترنت. تتمثل القوة الدافعة الرئيسية هنا في توحيد الوصول إلى الوظائف بحيث يمكنك توفيرها بعدة طرق مختلفة تتطور باستمرار. في الوقت نفسه ، تظل الوظائف متاحة ، لأن الوصول يعتمد على اتفاقيات عامة حول تفاعل الوظائف. الهدف الرئيسي من اللامركزية هو إضعاف التماسك ( http://bit.ly/2FpcUpf ) ، أي تسهيل التغييرات في الأجزاء الفردية للنظام ككل دون الحاجة إلى تغيير الأجزاء الأخرى.
اللامركزية والتنفيذ
إذا تعلمنا شيئًا ما من الوعود التي تم الوفاء بها بشكل غير مكتمل في وقت بنية الخدمات الموجهة بناءً على SOAP ، فإن التنفيذ المدار بعناية هو جانب أساسي في تنفيذ التوقعات الموجهة نحو الخدمة. حقق SOAP وعدًا بتوفير الوصول إلى الوظائف ، لكنه لم يتماشى مع المهمة التي لا تقل أهمية وهي إدارة تنفيذ المهام بشكل صحيح. وبالتالي ، على الرغم من أن SOAP كان مفيدًا (الوظائف التي لم تكن متوفرة سابقًا كخدمات) ، إلا أنها لم تلبي احتياجات بيئة أكثر مرونة وتطوراً.
تعقيد إدارة نظام API هو تذكر هذه المشكلة وتجنب الفخ الذي وقع عليه SOAP. وقال SOAP أن توافر الخدمات فقط هو المهم. كانت هذه خطوة أولى مهمة ، لكنها لم تسمح بالتعامل مع ضعف تماسك الوظائف. واجهات برمجة التطبيقات (APIs) ، وإذا ركزت بشكل خاص على تقنيات التنفيذ والنشر ، تتيح لنا الخدمات الميكروية إعادة التفكير في ما هو مهم لأنظمة الخدمة الكبيرة وكيفية إنشاء أنظمة لا تندرج في فخ SOAP.
مبدأ منصة
يتحدث الكثيرون عن المنصات ومناقشة واجهات برمجة التطبيقات وأهداف العمل الرئيسية. ومع ذلك ، فإنها قد تعني أشياء مختلفة تماما. من المهم أن تتذكر: إذا كان الأمر يبدو جيدًا على مستوى الأعمال لإنشاء شيء ما كمنصة ، فإن هذا لا يعني أن هذه هي الطريقة التي ينبغي تطويرها بها على المستوى التقني.
على مستوى الأعمال ، توفر المنصة شيئًا يمكن بناء عليه ، ولا يمكننا التعمق أكثر من هذه الصياغة الغامضة إلى حد ما. غالبًا ما تتأثر جاذبية مفهوم "المنصة" بعاملين رئيسيين.
- ما هي تغطية المنصة؟ بمعنى ، كم عدد المستخدمين الذين يمكن الوصول إليهم عن طريق إنشاء شيء ما على هذا النظام الأساسي؟ يتم تحديد ذلك عادةً بعدد المستخدمين أو المشتركين. غالبًا ما تكون هذه هي المعلمة الأكثر أهمية ، ويتم حسابها من خلال العدد الإجمالي أو باستخدام عوامل نوعية تحدد المستخدمين المناسبين ، والتي يمكن تغطيتها باستخدام هذا النظام الأساسي.
- ما هي الميزات التي لديها هذا النظام الأساسي؟ إذا قمت بإنشاء شيء عليه ، كيف يساعدك أو يحدك من حيث الدخل؟ وهل من السهل أيضًا تغيير النظام الأساسي لإضافة ميزات جديدة ، من الناحية المثالية دون الإضرار بمستخدميها؟
تعد هذه المعلمات مهمة جدًا للأعمال التجارية ، ولكن هناك غالبًا ما يتم نسيانها: دائمًا ما تجبر المنصات المستخدمين على الالتزام بقيود معينة ، لكنهم يقومون بذلك بطرق مختلفة. وهنا بعض الأمثلة.
- يمكن لأي شخص استخدام تطبيقات الويب وأي شيء يفي بمعايير الشبكة الأساسية. في أبسط الحالات ، هذا متصفح حديث مع دعم البرمجة النصية. يمكن لأي شخص إنشاءها وفتح الوصول إليها ، ويمكن لأي شخص استخدامها. لا يوجد عنصر مركزي يتحكم في تشغيل منصة الويب.
- تتشابه التطبيقات الموجودة على متجر تطبيقات Apple من حيث تطبيقات الويب ، ولكنها يتم توفيرها واستخدامها بطرق مختلفة تمامًا. يمكن تنزيلها فقط من متجر التطبيقات ، وبالتالي فإن لشركة Apple الحق الحصري في تحديد ما يمكن للمستخدمين تثبيته. بالإضافة إلى ذلك ، لا يمكن تشغيلها إلا على أجهزة iOS ، أي أن شركة أبل تحتكر بيع الأجهزة القادرة على استخدام هذه التطبيقات. يتم إنشاء التطبيقات في متجر التطبيقات خصيصًا لبيئة iOS ، أي أن الاستثمارات في إنشائها محدودة فقط بواسطة هذا النظام الأساسي. لاستخدام التطبيق على أي نظام أساسي آخر ، بما في ذلك الإنترنت ، يجب إعادة إنتاجه في بيئة تطوير مختلفة وحتى بلغة برمجة مختلفة ، مما يعني: يجب إعادة إنشاء جانب العميل للتطبيق من نقطة الصفر.
يمكنك تطبيق هذا القالب على كل من أنظمة API وفكرة إنشاء منصة API للتطبيقات.
في بعض الأحيان ، يشير النظام الأساسي لـ API إلى بيئة معينة توفر الوصول إلى API. قريبًا ، يبدأ الأمر في تشبه قليلاً حافلة خدمة المؤسسة التقليدية ، حيث يجب أن توفر منصة مماثلة البنية التحتية ، ويمكن الوصول إلى واجهات برمجة التطبيقات نظرًا لحقيقة أنها يمكن استخدامها.
في حالات أخرى ، عند الحديث عن منصة API ، فإنها تعني مجموعة مشتركة من المبادئ التي تستخدمها وتقدمها الخدمات. في هذه الحالة ، إذا أصبحت الخدمة جزءًا من النظام الأساسي ، فلن يكون لها أي علاقة بمكان وكيفية فتح الوصول إليها. إذا كانت الخدمات تلتزم بنفس المبادئ والبروتوكولات والقوالب ، فإنها توفر واجهات برمجة التطبيقات على هذا النظام الأساسي ، وبالتالي تصبح جزءًا من نظام API.
النوع الثاني من المنصة هو أكثر تجريدية ، ولكن في الوقت نفسه لديه المزيد من الميزات. بفصل ما هي الوظائف التي تؤديها وكيف تقوم بذلك ، فإنه يسهل مساهمة المستخدمين في النظام الأساسي. كما يفتح العديد من مسارات الابتكار ، مما يسمح للتطبيقات بتجربة أساليب التنفيذ دون المساس بقدرتهم على المساهمة في نظام API.
ومرة أخرى ، خذ الإنترنت كمثال. إذا نظرت فقط من وجهة نظر واجهة برمجة التطبيقات (API) ، فهي تتيح لك التغيير كثيرًا بمرور الوقت. على سبيل المثال ، شبكة توصيل المحتوى (CDN) غير مدمجة في الإنترنت نفسها. أصبح وجوده ممكنًا بسبب تعقيد محتوى الإنترنت ومرونة المتصفح ، مما يتيح لك إنشاء صفحات ويب بناءً على عدة مصادر مأخوذة ، ربما من أماكن مختلفة. قد يجادل المرء بأن إمكانية إنشاء شبكة CDN كانت موجودة بالفعل في مبادئ وبروتوكولات صفحات الويب الأولى ، لكن قالب CDN لم يظهر إلا عند نشوئه.
هذه القدرة على التكيف مع المهام الجديدة المطلوبة في أنظمة API. نحن نصمم نظامًا قائمًا على مبادئ وبروتوكولات مفتوحة وقابلة للتوسعة ، ولكن يمكننا تغييره ونريد تغييره إذا لزم الأمر. نقوم أيضًا بإنشاء قوالب دعم تساعد التطبيقات على حل المشكلات بشكل أكثر كفاءة ، ونريد تطوير هذه القوالب بمرور الوقت.
المبادئ والبروتوكولات والقوالب
الاستنتاج الرئيسي من القسم السابق: يجب ألا تتطلب المنصة طريقة واحدة محددة للقيام بشيء ما (أجب عن السؤال "كيف؟") أو مكان واحد محدد (أجب على السؤال "أين؟"). يتم إنشاء منصة جيدة للتطوير المستمر للهندسة المعمارية ، أي أن بنية المنصة (وليس فقط بنية المنتج) تتطور باستمرار ، ولم يتم تطويرها جميعًا في وقت واحد ، بحيث تظل بدون تغيير طوال وقت وجودها.
تطوير الهندسة المعمارية المستمر
التطوير المعماري المستمر هو منهجية للتطوير المستمر لأساسيات هندسة المنتجات. يتم إنشاء المنتجات الفردية باستخدام الأطر المعمارية الحالية ، ويمكن للتقارير المتعلقة بتطبيق هذه الأطر تحسين بنية المنتج ، مما يجعله أكثر كفاءة.
تكرس منهجية التطوير المرنة و DevOps لتحسين تطوير المنتجات الفردية. لا يتحدثون عن كيفية تحسين أساسيات هذه العملية بحيث تكون بنية النظام الأكثر كفاءة مفيدة لبنية المنتج. يحدث التطوير المستمر عندما يتم إنشاء منتجات فردية في بيئة العمل لنظام موجود. يسهّل النظام إنشاء منتجات جديدة ، ويساعد النظام في العثور على مجالات للتحسين ، وبالتالي إنشاء حلقة تغذية مرتدة.
يركز التطوير المستمر للبنية على تطوير إطار لا يضر بالمنتجات الحالية ويسمح بإنشاء مجموعات المنتجات. من الناحية المثالية ، تتطور أساسيات الهندسة المعمارية باستمرار بحيث تكون متوافقة مع الإصدارات السابقة ، وبالتالي فإن تشغيل النظام لا يكاد يتعطل.
لتحقيق التطوير المستمر للهندسة المعمارية ، يجب أن يكون النظام الأساسي مبنيًا على المبادئ والبروتوكولات والقوالب. يمكننا توضيح هذه النقطة مع منصة على شبكة الإنترنت. من المعروف منذ زمن طويل أن الإنترنت مستقر ومرن بشكل لا يصدق في نفس الوقت. على مدار الثلاثين عامًا الماضية ، لم يتغير هيكلها الأساسي ، ولكن بالطبع تطورت بشكل ملحوظ. كيف أصبح هذا التناقض الواضح ممكنًا؟ بعد كل شيء ، تواجه الأنظمة الأخرى مشاكل أسرع بكثير ، تتحرك في مسارات أقل جذرية.
أحد الأسباب الرئيسية هو أنه لا يوجد شيء على الإنترنت يوضح كيفية تنفيذ خدمة معينة أو تنشيطها. يمكن تنفيذ الخدمات بأي لغة ، وبالطبع فإنها تتغير على مر السنين ، لأن لغات البرمجة تتغير أيضًا. يتم توفيرها باستخدام أي بيئة عمل - في البداية كانت الخوادم الموجودة في الأقبية ، والموجودة الآن على شبكة الإنترنت نفسها ، وفي الآونة الأخيرة ، ظهر أيضًا التخزين السحابي. يمكن استخدام الخدمات بواسطة أي برنامج عميل - لقد تغيرت أيضًا بشكل كبير من متصفحات سطر الأوامر البسيطة إلى المتصفحات الرسومية المعقدة على الهواتف المحمولة الحديثة. مع التركيز فقط على الواجهة التي تحدد كيفية التعرف على المعلومات وتبادلها وإظهارها ، اتضح أن بنية الإنترنت تتكيف بشكل أفضل مع النمو الطبيعي أكثر من أي نظام تكنولوجيا معلومات معقد رأيناه. أسباب هذا بسيطة بشكل مدهش.
- المبادئ هي مفاهيم أساسية مبنية على أساس النظام الأساسي. في حالة الإنترنت ، يتمثل أحد هذه المبادئ في أن الموارد يتم التعرف عليها بواسطة معرف مورد موحد (URI) ، ومن ثم يمنح بروتوكول التعرف على URI الإذن بالتفاعل مع هذه الموارد. وبالتالي ، على الرغم من أنه يمكننا (على الأقل نظريًا) الانتقال إلى الإنترنت بدون HTTP (بمعنى أننا نتحرك بالفعل لأن البروتوكولات في كل مكان تتغير إلى HTTPS) ، فمن الصعب أن نتخيل أنه من الممكن الانتقال إلى الإنترنت دون موارد. تنعكس المبادئ في أنماط واجهة برمجة التطبيقات ، لأن الأساليب تستند إلى مفاهيم أساسية مختلفة.
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»
»
»
25% —
APIe-mail .