أفضل الممارسات لتصميم الخادم الوكيل لواجهة برمجة التطبيقات وتطويره

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

الغرض من هذا المستند هو تقديم مجموعة من المعايير وأفضل الممارسات ل التطوير باستخدام Apigee Edge. تشمل المواضيع التي يتم تناولها هنا التصميم والترميز واستخدام السياسات والمراقبة وتصحيح الأخطاء. تم جمع المعلومات استنادًا إلى تجربة المطوّرين الذين يعملون مع Apigee لتنفيذ برامج ناجحة لواجهات برمجة التطبيقات. هذه وثيقة قابلة للتعديل وسيتم تعديلها من حين لآخر.

بالإضافة إلى الإرشادات الواردة هنا، قد يكون من المفيد أيضًا الاطّلاع على مشاركة المنتدى Apigee Edge Antipatterns.

معايير التطوير

التعليقات والمستندات

  • قدِّم تعليقات مضمّنة في إعدادات ProxyEndpoint وTargetEndpoint. تعمل التعليقات على تحسين سهولة قراءة "المسارات"، خاصةً عندما لا تكون أسماء ملفات السياسات مكتوبة بلغة وصفية بشكلٍ كافٍ لشرح الوظيفة الأساسية للمسار.
  • أضِف تعليقات مفيدة. تجنَّب التعليقات الواضحة.
  • استخدِم مسافات بيضاء متسقة بين السطور، واضبط المحاذاة العمودية بشكلٍ متسق، وما إلى ذلك.

الترميز بأسلوب إطار العمل

يتضمن الترميز بأسلوب إطار العمل تخزين موارد الوكيل لواجهة برمجة التطبيقات في نظام التحكّم في الإصدارات الخاص بك لإعادة استخدامها في بيئات التطوير المحلية. على سبيل المثال، لإعادة استخدام سياسة، يمكنك تخزينها في أداة التحكّم في المصدر حتى يتمكّن المطوّرون من مزامنتها واستخدامها في بيئات تطوير الخادم الوكيل الخاصة بهم.

  • لتفعيل أسلوب DRY ("عدم تكرار نفسك")، يجب أن تُنفِّذ إعدادات السياسات والنصوص البرمجية عند الإمكان وظائف مخصّصة وقابلة لإعادة الاستخدام. على سبيل المثال، يمكن تسمية سياسة مخصّصة لاستخراج مَعلمات طلب البحث من رسائل الطلبات باسم ExtractVariables.ExtractRequestParameters. يمكن تسمية السياسة المخصّصة لإدراج عناوين CORS بـ AssignMessage.SetCORSHeaders. ويمكن بعد ذلك تخزين هذه السياسات في نظام التحكّم في المصدر وإضافتها إلى كل خادم وكيل لواجهة برمجة التطبيقات يحتاج إلى استخراج المَعلمات أو ضبط رؤوس CORS، بدون الحاجة إلى إنشاء إعدادات مكرّرة (وبالتالي أقل قابلية للإدارة).
  • تنظيف السياسات والموارد غير المستخدمة (JavaScript وJava وXSLT وما إلى ذلك) من الوكلاء لـ API، خاصةً الموارد الكبيرة التي يمكن أن تبطئ إجراءات الاستيراد والنشر

اصطلاحات التسمية

  • يجب أن تكون سمة السياسة name متطابقة مع اسم ملف السياسة بتنسيق XML.
  • يجب أن تكون سمة name لسياسة Script وServiceCallout متطابقة مع اسمملف المرجع.
  • يجب أن يصف DisplayName وظيفة السياسة بدقة لشخص لم يعمل مع هذا الوكيل لواجهة برمجة التطبيقات من قبل.
  • أدخِل أسماء للسياسات وفقًا لوظيفتها. تنصحك شركة Apigee بإنشاء اصطلاح تسمية ثابت لسياساتك. على سبيل المثال، استخدِم بادئات قصيرة متبوعة بسلسلة من الكلمات الوصفية مفصولة بشرطات. على سبيل المثال، AM-xxx لسياسات AssignMessage. راجِع أيضًا أداة apigeelint.
  • استخدِم الإضافات المناسبة لملفات الموارد، مثل .js لملف JavaScript و.py لملف Python و.jar لملف Java JAR.
  • يجب أن تكون أسماء المتغيّرات متسقة. إذا اخترت نمطًا، مثل camelCase أو under_score، استخدِمه في جميع أنحاء الخادم الوكيل لواجهة برمجة التطبيقات.
  • استخدِم بادئات المتغيّرات، حيثما أمكن، لتنظيم المتغيّرات استنادًا إلى الغرض منها، على سبيل المثال، Consumer.username وConsumer.password.

تطوير الخادم الوكيل لواجهة برمجة التطبيقات

اعتبارات التصميم الأولية

  • للحصول على إرشادات حول تصميم واجهات برمجة التطبيقات RESTful، نزِّل الكتاب الإلكتروني Web API Design: The Missing Link.
  • استفِد من سياسات Apigee Edge ووظائفها كلما أمكن ذلك لإنشاء أدوات وكيل لواجهات برمجة التطبيقات. تجنَّب ترميز كل منطق الخادم الوكيل في موارد JavaScript أو Java أو Python.
  • أنشئ مسارات عمل بطريقة منظمة. إنّ مسارات متعددة، يتضمّن كلّ منها شرطًا واحدًا، هي أفضل من المرفقات الشَرطية المتعدّدة في مسارات ما قبل الإجراء وما بعد الإجراء نفسها.
  • كإجراء احتياطي، أنشئ خادم وكيل تلقائيًا لواجهة برمجة التطبيقات باستخدام BasePath لـ ProxyEndpoint‏ /. ويمكن استخدام ذلك لإعادة توجيه طلبات واجهة برمجة التطبيقات الأساسية إلى موقع إلكتروني للمطوّر، أو لعرض ردّ مخصّص، أو لتنفيذ إجراء آخر أكثر فائدة من عرض القيمة التلقائية messaging.adaptors.http.flow.ApplicationNotFound.
  • استخدِم موارد TargetServer لفصل إعدادات TargetEndpoint عن عناوين URL المحدّدة، ما يتيح الترويج على مستوى جميع البيئات.
    راجِع مقالة موازنة الحمّل على مستوى خوادم الخلفية.
  • إذا كان لديك عدّة قواعد توجيه، أنشئ قاعدة واحدة كقاعدة "تلقائية"، أي قاعدة توجيه بدون أيّ شرط. تأكَّد من أنّ قاعدة التوجيه التلقائية محدّدة في آخر قائمة المسارات المشروطة. يتم تقييم RouteRules من الأعلى إلى الأسفل في ProxyEndpoint.
    يمكنك الاطّلاع على مرجع إعداد الخادم الوكيل لواجهة برمجة التطبيقات.
  • حجم حِزمة الوكيل لواجهة برمجة التطبيقات: لا يمكن أن يزيد حجم حِزم وكلاء واجهات برمجة التطبيقات عن 15 ميغابايت. في Apigee Edge لخدمات Private Cloud، يمكنك تغيير الحدّ الأقصى للحجم من خلال تعديل سمة thrift_framed_transport_size_in_mb في المواقع التالية: cassandra.yaml (في Cassandra) وconf/apigee/management-server/repository.properties.
  • إصدارات واجهة برمجة التطبيقات: للاطّلاع على آراء Apigee واقتراحاتها بشأن إصدارات واجهة برمجة التطبيقات، راجِع قسم "الإصدارات" في الدليل الإلكتروني تصميم واجهة برمجة التطبيقات على الويب: الرابط المفقود.

تفعيل سياسة مشاركة الموارد المتعددة المصادر (CORS)

قبل نشر واجهات برمجة التطبيقات، عليك تفعيل مشاركة الموارد المتعدّدة المصادر (CORS) في الخوادم الوكيلة لواجهات برمجة التطبيقات لتتمكّن من معالجة طلبات المصادر المتعددة من جهة العميل.

مشاركة الموارد المتعدّدة المصادر (CORS) هي آلية عادية تسمح لواجهات XMLHttpRequest (XHR) المستندة إلى JavaScript والتي يتم تنفيذها في صفحة ويب بالتفاعل مع الموارد من نطاقات غير مصدر المحتوى. مشاركة الموارد المتعدّدة المصادر هي حلّ شائع لتنفيذ سياسة المصادر المشترَكة التي تفرضها جميع المتصفّحات. على سبيل المثال، إذا أجريت طلب XHR إلى Twitter API من رمز JavaScript الذي يتم تنفيذه في المتصفّح، سيتعذّر إكمال الطلب. ويرجع ذلك إلى أنّ النطاق الذي يعرض الصفحة لمتصفّحك ليس هو نفسه النطاق الذي يعرض Twitter API. توفّر مشاركة الموارد المتعددة المصادر (CORS) حلًّا لهذه المشكلة من خلال السماح للخوادم "بالموافقة" إذا أرادت توفير مشاركة موارد متعددة المصادر.

للحصول على معلومات عن تفعيل سياسة مشاركة الموارد المتعددة المصادر (CORS) على الخوادم الوكيلة لواجهات برمجة التطبيقات قبل نشر واجهات برمجة التطبيقات، يُرجى الاطّلاع على مقالة إضافة دعم سياسة مشاركة الموارد المتعددة المصادر (CORS) إلى خادم وكيل لواجهة برمجة التطبيقات.

حجم حمولة الرسالة

لتجنُّب مشاكل الذاكرة في Edge، يتم حصر حجم الحمولة في الرسالة بـ 10 ميغابايت. يؤدي تجاوز هذه المقاسات إلى ظهور خطأ protocol.http.TooBigBody.

تتم أيضًا مناقشة هذه المشكلة في مشاركة "منتدى Apigee" هذه.

في ما يلي الاستراتيجيات المقترَحة للتعامل مع أحجام الرسائل الكبيرة في Edge:

  • بث الطلبات والردود يُرجى العِلم أنّه عند البث، لن تتمكّن السياسات من الوصول إلى محتوى الرسالة. راجِع طلبات البث والاستجابات.
  • في الإصدار 4.15.07 من Edge for Private Cloud والإصدارات الأقدم، عدِّل ملف معالج الرسائل http.properties لزيادة الحدّ الأقصى في المَعلمة HTTPResponse.body.buffer.limit. احرص على إجراء الاختبار قبل نشر التغيير في قناة الإصدار العلني.
  • في الإصدار 4.16.01 من Edge for Private Cloud والإصدارات الأحدث، يجب أن تتضمّن الطلبات التي تحتوي على حمولة عنوان Content-Length، أو في حال البث، يجب أن يتضمّن العنوان "Transfer-Encoding: chunked". بالنسبة إلى طلب POST إلى خادم وكيل لواجهة برمجة التطبيقات يحتوي على حمولة فارغة، يجب ضبط Content-Length على 0.
  • في الإصدار 4.16.01 من Edge for Private Cloud والإصدارات الأحدث، اضبط السمات التالية فيملف ‎/opt/apigee/router.properties أو ملف message-processor.properties لتغيير الحدود. اطّلِع على مقالة ضبط الحد الأقصى لحجم الرسالة على جهاز التوجيه أو وحدة معالجة الرسائل للاطّلاع على مزيد من المعلومات.

    تحتوي كلتا السمتَين على القيمة التلقائية "10m" التي تتوافق مع 10 ميغابايت:
    • conf_http_HTTPRequest.body.buffer.limit
    • conf_http_HTTPResponse.body.buffer.limit

معالجة الأخطاء

  • يمكنك الاستفادة من FaultRules لمعالجة جميع حالات حدوث الأعطال. (تُستخدَم سياسات RaiseFault لإيقاف تدفق الرسائل ونقلها إلى مسار FaultRules.)
  • ضمن مسار FaultRules، استخدِم سياسات AssignMessage لإنشاء استجابة الخطأ، وليس سياسات RaiseFault. تنفيذ سياسات AssignMessage بشكل مشروط استنادًا إلى نوع الخطأ الذي يحدث
  • تتضمّن دائمًا معالِج أخطاء تلقائيًا "لجميع الأخطاء" حتى يمكن ربط الأخطاء التي ينشئها النظام بتنسيقات استجابة الأخطاء التي يحدّدها العميل.
  • إذا أمكن، احرص دائمًا على أن تتطابق الردود على الأخطاء مع أي تنسيقات عادية متاحة في شركتك أو مشروعك.
  • استخدِم رسائل خطأ مفيدة ومفهومة تقترح حلًا لحالة الخطأ.

يُرجى الاطّلاع على معالجة الأعطال.

للاطّلاع على أفضل الممارسات في المجال، يُرجى الاطّلاع على تصميم استجابة الخطأ في أسلوب RESTful.

الاستمرارية

خرائط المفاتيح/القيم

  • استخدِم خرائط المفاتيح/القيم فقط مع مجموعات بيانات محدودة. ولم يتم تصميمها لتخزين البيانات على المدى الطويل.
  • يجب مراعاة الأداء عند استخدام خرائط المفاتيح/القيم لأنّ هذه المعلومات يتم تخزينها في قاعدة بيانات Cassandra.

راجِع سياسة عمليات ربط القيم بالمفاتيح.

التخزين المؤقت للاستجابة

  • لا تملأ ذاكرة التخزين المؤقت للاستجابة إذا لم يكن الاستجابة ناجحة أو إذا كان الطلب ليس طلب GET. يجب عدم تخزين عمليات الإنشاء والتعديل والحذف مؤقتًا. <SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation>
  • املأ ذاكرة التخزين المؤقت بنوع محتوى واحد متّسق (مثل XML أو JSON). بعد retrieving a responseCache entry، يمكنك تحويله إلى نوع المحتوى المطلوب باستخدام JSONtoXML أو XMLToJSON. سيؤدي ذلك إلى منع تخزين بيانات مضاعفة أو ثلاثية أو أكثر.
  • تأكَّد من أنّ مفتاح ذاكرة التخزين المؤقت كافٍ لمتطلبات التخزين المؤقت. في كثير من الحالات، يمكن استخدام request.querystring كمعرّف فريد.
  • لا تُدرِج مفتاح واجهة برمجة التطبيقات (client_id) في مفتاح ذاكرة التخزين المؤقت، ما لم يكن ذلك مطلوبًا بشكل صريح. في أغلب الأحيان، ستُرجع واجهات برمجة التطبيقات التي يتم تأمينها بمفتاح فقط البيانات نفسها لجميع العملاء لطلب معيّن. لا يُعدّ تخزين القيمة نفسها لعدد من الإدخالات استنادًا إلى مفتاح واجهة برمجة التطبيقات إجراءً فعّالاً.
  • حدِّد فواصل زمنية مناسبة لانتهاء صلاحية ذاكرة التخزين المؤقت لتجنُّب عمليات القراءة غير الصالحة.
  • حاول، كلما أمكن، تنفيذ سياسة ذاكرة التخزين المؤقت للاستجابة التي تملأ ذاكرة التخزين المؤقت في PostFlow للاستجابة ProxyEndpoint في أقرب وقت ممكن. بعبارة أخرى، يجب تنفيذه بعد خطوات الترجمة والتوسّط، بما في ذلك التوسّط المستنِد إلى JavaScript والتحويل بين JSON وXML. من خلال تخزين البيانات التوسّطية مؤقتًا، يمكنك تجنُّب تكلفة الأداء المترتّبة على تنفيذ مرحلة التوسّط في كل مرة تسترجع فيها البيانات المخزّنة مؤقتًا.

    يُرجى العلم أنّه قد تحتاج إلى تخزين البيانات غير التوسّطية مؤقتًا بدلاً من ذلك إذا كان التوسّط يؤدي إلى اختلاف في الردّ من طلب إلى آخر.

  • يجب أن تحدث سياسة ذاكرة التخزين المؤقت للردّ للبحث عن إدخال ذاكرة التخزين المؤقت في مرحلة ما قبل معالجة طلب ProxyEndpoint. تجنَّب تنفيذ الكثير من العمليات المنطقية، باستثناء إنشاء مفتاح التخزين المؤقت، قبل عرض إدخال في ذاكرة التخزين المؤقت. وبخلاف ذلك، يتم تقليل فوائد التخزين المؤقت.
  • بشكل عام، يجب دائمًا إبقاء البحث في ذاكرة التخزين المؤقت للردّ أقرب ما يمكن إلى طلب العميل. في المقابل، يجب إبقاء عدد عناصر ذاكرة التخزين المؤقت للاستجابة قريبًا قدر الإمكان من العميل الاستجابة.
  • عند استخدام سياسات متعددة ومختلفة لذاكرة التخزين المؤقت للاستجابة في الخادم الوكيل، اتّبِع الإرشادات التالية لضمان السلوك المنفصل لكل منها:
    • تنفيذ كل سياسة استنادًا إلى شروط متعارضة سيساعد ذلك في ضمان تنفيذ إحدى سياسات ذاكرة التخزين المؤقت للردّ المتعدّدة فقط.
    • حدِّد موارد ذاكرة تخزين مؤقت مختلفة لكل سياسة ذاكرة تخزين مؤقت للاستجابة. يمكنك تحديد مورد ملف التخزين المؤقت في عنصر <CacheResource> الخاص بالسياسة.

راجِع سياسة ذاكرة التخزين المؤقت للردّ.

السياسة والرمز المخصّص

هل هو رمز سياسة أم رمز مخصّص؟

  • استخدِم السياسات المضمّنة أولاً وقبل كل شيء (عند الإمكان). تم تعزيز سياسات Apigee وتحسينها وتوفير الدعم لها. على سبيل المثال، استخدِم سياستَي AssignMessage وExtractVariables العاديتَين بدلاً من JavaScript (عند الإمكان) لإنشاء حِزم بيانات، واستخراج المعلومات من حِزم البيانات (XPath وJSONPath) وما إلى ذلك.
  • يُفضّل استخدام JavaScript على Python وJava. ومع ذلك، إذا كان الأداء هو المتطلّب الأساسي، يجب استخدام Java بدلاً من JavaScript.

JavaScript

  • استخدِم JavaScript إذا كان أكثر سهولة من سياسات Apigee (على سبيل المثال، عند ضبط target.url لعدة تركيبات مختلفة لعناوين الموارد المتسلسلة).
  • تحليل الحمولة المعقدة، مثل التنقّل في عنصر JSON والترميز/فك الترميز باستخدام Base64
  • تفرض سياسة JavaScript حدًا زمنيًا، لذلك يتم حظر الحلقات المتكررة.
  • استخدِم دائمًا خطوات JavaScript وضع الملفات في مجلد jsc resources. يُجمِّع نوع سياسة JavaScript الرمز البرمجي مسبقًا في وقت النشر.

اطّلِع على العناصر الوكيلة لواجهات برمجة التطبيقات باستخدام JavaScript.

Java

  • استخدِم Java إذا كان الأداء هو الأولوية القصوى، أو إذا تعذّر تنفيذ المنطق في JavaScript.
  • تضمين ملفات مصدر Java في تتبُّع رمز المصدر

اطّلِع على مقالتَي تحويل الاستجابة إلى الأحرف الكبيرة باستخدام تعليق توضيحي في Java وسياسة تعليقات Java التوضيحية للحصول على معلومات عن استخدام Java في الخوادم الوكيلة لواجهات برمجة التطبيقات.

Python

  • لا تستخدِم لغة Python إلا إذا كان ذلك ضروريًا للغاية. يمكن أن تؤدي نصوص Python البرمجية إلى حدوث اختناقات في الأداء في عمليات التنفيذ البسيطة، لأنّها يتم تفسيرها أثناء التشغيل.

نصائح حول النصوص البرمجية (Java وJavaScript وPython)

  • استخدِم عبارة try/catch شاملة أو ما يعادلها.
  • يجب طرح استثناءات ذات مغزى ورصدها بشكل صحيح لاستخدامها في الردود على الأخطاء.
  • طرح الاستثناءات ورصدها في وقت مبكر لا تستخدِم المحاولة/المعالجة الشاملة للتعامل مع كل الاستثناءات.
  • أجرِ عمليات التحقّق من القيم الخالية والقيم غير المحدّدة، عند الضرورة. ومن الأمثلة على الحالات التي يجب فيها إجراء ذلك هو عند استرداد متغيّرات المسار الاختيارية.
  • تجنَّب إجراء طلبات HTTP/S داخل طلب رمز نصي. بدلاً من ذلك، استخدِم سياسة Apigee ServiceCallout لأنّ السياسة تتعامل مع عمليات الربط بسلاسة.

JavaScript

  • تتيح JavaScript على منصّة واجهة برمجة التطبيقات استخدام XML من خلال E4X.

اطّلِع على نموذج كائنات JavaScript.

Java

  • عند الوصول إلى حِزم بيانات الرسائل، جرِّب استخدام context.getMessage() بدلاً من context.getResponseMessage أو context.getRequestMessage. يضمن ذلك أنّه يمكن للرمز البرمجي استرداد الحمولة، في كلّ من عمليات تدفق الطلب والاستجابة.
  • استورِد المكتبات إلى مؤسسة أو بيئة Apigee Edge ولا تُدرِجها فيملف JAR. يؤدي ذلك إلى تقليل حجم الحِزمة وسيسمح لملفات JAR الأخرى بالوصول إلى مستودع المكتبة نفسه.
  • استورِد ملفات JAR باستخدام واجهة برمجة التطبيقات Apigee resources API بدلاً من تضمينها داخل مجلد موارد الوكيل API. سيؤدي ذلك إلى تقليل أوقات النشر والسماح لملفّات JAR نفسها بالإشارة إلى مثبّتات لواجهات برمجة التطبيقات متعددة. ومن المزايا الأخرى عزل أداة تحميل الفئات.
  • لا تستخدِم Java لمعالجة الموارد (مثل إنشاء مجموعات معالجة مثيلَي برمجة شاردت وإدارتها).

راجِع مقالة تحويل الاستجابة إلى أحرف كبيرة باستخدام تعليق توضيحي في Java.

Python

  • رمي استثناءات ذات مغزى ورصدها بشكل صحيح لاستخدامها في استجابات أخطاء Apigee

اطّلِع على سياسة ملف Python script.

ServiceCallouts

  • هناك العديد من حالات الاستخدام الصالحة لاستخدام سلسلة الخوادم الوكيلة، حيث يتم استخدام طلب بيانات خدمة في خادم وكيل لواجهة برمجة التطبيقات لاستدعاء خادم وكيل آخر لواجهة برمجة التطبيقات. في حال استخدام سلسلة الخوادم الوكيلة، احرص على تجنُّب "حلقة أبدية للطلبات المتكرّرة" التي تؤدي إلى خادم وكيل واجهة برمجة التطبيقات نفسه.

    إذا كنت تربط بين الخوادم الوكيلة في المؤسسة والبيئة نفسها، احرص على الاطّلاع على ربط خوادم الوكيلة لواجهة برمجة التطبيقات معًا لمعرفة المزيد من المعلومات عن تنفيذ اتصال محلي يتجنّب تكاليف المعالجة الزائدة غير الضرورية للشبكة.

  • أنشئ رسالة طلب ServiceCallout باستخدام سياسة AssignMessage، واملأ عنصر الطلب في متغيّر رسالة. (يشمل ذلك ضبط الحمولة والمسار وطريقة طلب البيانات).
  • يتطلّب عنوان URL الذي تم ضبطه ضمن السياسة مواصفات البروتوكول، ما يعني أنّه لا يمكن تحديد جزء البروتوكول من عنوان URL، مثل https://، باستخدام متغيّر. يجب أيضًا استخدام متغيّرات منفصلة لجزء النطاق من عنوان URL ولل الجزء المتبقّي من عنوان URL. على سبيل المثال: https://{domain}/{path}
  • تخزين عنصر الاستجابة لعنصر ServiceCallout في متغيّر رسالة منفصل يمكنك بعد ذلك تحليل متغيّر الرسالة والحفاظ على الحمولة الأصلية للرسالة سليمة لاستخدامها من قِبل سياسات أخرى.

يُرجى الاطّلاع على سياسة بيانات الاتصال بخدمة الدعم.

الوصول إلى الكيانات

سياسة AccessEntity

  • للحصول على أداء أفضل، ابحث عن التطبيقات باستخدام uuid بدلاً من اسم التطبيق.

راجِع سياسة ملف تعريف "جهة الوصول".

التسجيل

  • استخدِم سياسة syslog شائعة في جميع الحِزم وداخل الحزمة نفسها. سيؤدي ذلك إلى الحفاظ على تنسيق تسجيل متسق.

اطّلِع على سياسة تسجيل الرسائل.

المراقبة

ليس مطلوبًا من عملاء Cloud التحقّق من المكوّنات الفردية لخدمة Apigee Edge (أجهزة التوجيه، ومعالجات الرسائل، وما إلى ذلك). يرصد فريق العمليات العالمية في Apigee بدقة كل المكوّنات، بالإضافة إلى عمليات التحقّق من حالة واجهة برمجة التطبيقات، بناءً على طلبات التحقّق من حالة العميل.

Apigee Analytics

يمكن أن تقدّم "إحصاءات Google" مراقبة واجهة برمجة التطبيقات غير الملحّة عند قياس النسب المئوية للأخطاء.

اطّلِع على لوحات بيانات "إحصاءات Google".

التتبّع

إنّ أداة التتبّع في واجهة مستخدم إدارة API Edge مفيدة في تصحيح أخطاء واجهة برمجة التطبيقات أثناء التشغيل، وذلك أثناء عملية تطوير واجهة برمجة التطبيقات أو تشغيلها.

راجِع مقالة استخدام أداة التتبُّع.

الأمان