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

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

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

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

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

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

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

الترميز المستند إلى إطار العمل

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

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

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

• يجب أن تتطابق سمة السياسة 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.
• إنشاء مسارات العمل بطريقة منظَّمة يُفضَّل استخدام تدفقات متعددة، كل منها يتضمّن شرطًا واحدًا، على استخدام مرفقات شرطية متعددة لنفس PreFlow وPostflow.
• كإجراء احتياطي، أنشئ خادمًا وكيلاً تلقائيًا لواجهة برمجة التطبيقات باستخدام BasePath في ProxyEndpoint بقيمة /. ويمكن استخدام ذلك لإعادة توجيه طلبات واجهة برمجة التطبيقات الأساسية إلى موقع إلكتروني خاص بالمطوّر، أو لعرض ردّ مخصّص، أو لتنفيذ إجراء آخر أكثر فائدة من عرض messaging.adaptors.http.flow.ApplicationNotFound التلقائي.

• استخدِم موارد TargetServer لفصل إعدادات TargetEndpoint عن عناوين URL المحدّدة، ما يتيح إمكانية الترويج في جميع البيئات.
  اطّلِع على موازنة التحميل على خوادم الخلفية.
• إذا كان لديك عدة RouteRules، أنشئ واحدة كـ "تلقائية"، أي كـ RouteRule بدون شرط. تأكَّد من تحديد RouteRule التلقائية في آخر قائمة الطرق الشرطية. يتم تقييم RouteRules من الأعلى إلى الأسفل في ProxyEndpoint.
  راجِع مرجع إعداد خادم وكيل لواجهة برمجة التطبيقات.
• حجم حِزمة خادم وكيل واجهة برمجة التطبيقات: يجب ألا يزيد حجم حِزم خادم وكيل واجهة برمجة التطبيقات عن 15 ميغابايت. في Apigee Edge للسحابة الخاصة، يمكنك تغيير الحد الأقصى للحجم من خلال تعديل السمة thrift_framed_transport_size_in_mb في المواقع التالية: cassandra.yaml (في Cassandra) وconf/apigee/management-server/repository.properties.
• إصدارات واجهة برمجة التطبيقات: للاطّلاع على أفكار Apigee واقتراحاتها بشأن إصدارات واجهة برمجة التطبيقات، راجِع قسم "الإصدارات" في الكتاب الإلكتروني تصميم واجهة برمجة تطبيقات الويب: الحلقة المفقودة.

تفعيل ميزة "مشاركة المراجع مع نطاقات خارجية" (CORS)

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

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

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

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

لمنع حدوث مشاكل في الذاكرة في 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 بشكل مشروط استنادًا إلى نوع الخطأ الذي يحدث.
• يتضمّن دائمًا معالج أخطاء تلقائيًا "شاملًا" حتى يمكن ربط الأخطاء التي ينشئها النظام بتنسيقات استجابة الأخطاء التي يحدّدها العميل.
• إذا أمكن، احرص دائمًا على أن تتطابق الردود التي تشير إلى حدوث خطأ مع أي تنسيقات عادية متوفرة في شركتك أو مشروعك.
• استخدِم رسائل خطأ واضحة ومفهومة تقترح حلاً لحالة الخطأ.

اطّلِع على التعامل مع الأخطاء.

للاطّلاع على أفضل الممارسات في المجال، راجِع تصميم الردود على الأخطاء المتوافقة مع REST.

الثبات

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

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

اطّلِع على سياسة عمليات خريطة القيم الرئيسية.

التخزين المؤقت للردود

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

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

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

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

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

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

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

JavaScript

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

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

جافا

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

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

Python

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

وسائل الشرح النصية (Java وJavaScript وPython)

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

JavaScript

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

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

جافا

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

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

Python

• طرح استثناءات مفيدة والتعامل معها بشكل صحيح لاستخدامها في ردود الأخطاء في Apigee

اطّلِع على سياسة نصوص Python البرمجية.

ServiceCallouts

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

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

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

يُرجى الاطّلاع على سياسة ميزة "الرد على المكالمات".

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

سياسة AccessEntity

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

راجِع سياسة كيان الوصول.

التسجيل

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

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

المراقبة

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

Apigee Analytics

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

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

التتبّع

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

اطّلِع على استخدام أداة "التتبُّع".

الأمان

• استخدِم سياسات فرض القيود على عناوين IP للحدّ من الوصول إلى بيئة الاختبار. السماح بالوصول لعناوين IP الخاصة بأجهزة التطوير أو بيئاته وحظر جميع العناوين الأخرى سياسة AccessControl
• يجب دائمًا تطبيق سياسات حماية المحتوى (JSON و/أو XML) على خوادم وكيلة لواجهة برمجة التطبيقات يتم نشرها في بيئة الإنتاج. سياسة JSONThreatProtection
• اطّلِع على المواضيع التالية لمعرفة المزيد من أفضل ممارسات الأمان:
  • سياسة XMLThreatProtection
  • سياسة RegularExpressionProtection
  • سياسة SOAPMessageValidation