استخدام تكوين السياسة

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

في هذا الموضوع، ستتعرَّف على كيفية إنشاء محتوى مركّب باستخدام تركيبة السياسة. تكوين السياسة هو نمط خادم وكيل Apigee يسمح بدمج النتائج من خلفية متعددة. المستهدفة في رد واحد باستخدام السياسات.

للحصول على نظرة عامة حول تكوين السياسة، يمكن مراجعة "نمط تركيبة السياسة" في دليل استخدام خادم وكيل لواجهة برمجة التطبيقات الأنماط.

تنزيل نموذج الرمز وتجربته

لمحة عن مثال كتاب الطبخ هذا

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

يستخدم المثال الذي نوقش هنا تكوين السياسة لدمج البيانات من هاتين القائمتين واجهات برمجة التطبيقات العامة:

يطلب مطوِّرو التطبيقات الخادم الوكيل لواجهة برمجة التطبيقات هذا مع مَعلمتَي طلب بحث، وهما رمز بريدي وبلد. المعرِّف:

$ curl "http://{myorg}-test.apigee.net/policy-mashup-cookbook?country=us&postalcode=08008"

الاستجابة هي كائن JSON يتضمن الموقع المشفر جغرافيًا (خط العرض/خط الطول) وسط منطقة الرمز البريدي المقدّمة إلى جانب الارتفاع في ذلك الرمز الجغرافي الموقع. 

{  
   "ElevationResponse":{  
      "status":"OK",
      "result":{  
         "location":{  
            "lat":"39.7500713",
            "lng":"-74.1357407"
         },
         "elevation":"0.5045232",
         "resolution":"76.3516159"
      }
   }
}

قبل البدء

للحصول على نظرة عامة مختصرة حول نمط تركيبة السياسة، يمكنك قراءة القسم "السياسة" نمط التكوين" في دليل استخدام خادم وكيل لواجهة برمجة التطبيقات الأنماط.

قبل أن تستكشف مثال كتاب الطبخ هذا، يجب أن تكون على دراية بهذه النقاط الأساسية المفاهيم:

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

إذا كنت قد نزّلت نموذج الرمز، يمكنك العثور على جميع الملفات التي تمت مناقشتها في هذا في المجلد النموذجي mashup-policy-cookbook. الأقسام التالية سنناقش نموذج التعليمات البرمجية بالتفصيل.

شخصية انسيابية

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

في نموذج التنزيل، يمكنك العثور على ملف XML هذا في الملف. doc-samples/policy-mashup-cookbook/apiproxy/proxies/default.xml

<ProxyEndpoint name="default">
  <Flows>
    <Flow name="default">
      <Request>
            <!-- Generate request message for the Google Geocoding API -->
            <Step><Name>GenerateGeocodingRequest</Name></Step>
            <!-- Call the Google Geocoding API -->
            <Step><Name>ExecuteGeocodingRequest</Name></Step>
            <!-- Parse the response and set variables -->
            <Step><Name>ParseGeocodingResponse</Name></Step>
            <!-- Generate request message for the Google Elevation API -->
            <Step><Name>AssignElevationParameters</Name></Step>
      </Request>
      <Response>
            <!-- Parse the response message from the Elevation API -->
            <Step><Name>ParseElevationResponse</Name></Step>
            <!-- Generate the final JSON-formatted response with JavaScript -->
            <Step><Name>GenerateResponse</Name></Step>
      </Response>
    </Flow>
  </Flows>

  <HTTPProxyConnection>
    <!-- Add a base path to the ProxyEndpoint for URI pattern matching-->
    <BasePath>/policy-mashup-cookbook</BasePath>
    <!-- Listen on both HTTP and HTTPS endpoints -->
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
  <RouteRule name="default">
    <!-- Connect ProxyEndpoint to named TargetEndpoint under /targets -->
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

فيما يلي ملخص لعناصر التدفق.

  • &lt;Request&gt; - <الطلب> عنصرًا من عدة عناصر &lt;Step&gt; عناصر. وتستدعي كل خطوة إحدى السياسات التي سننشئها خلال حول هذا الموضوع. تهتم هذه السياسات بإنشاء رسالة طلب وإرسالها تحليل الرد. في نهاية هذا الموضوع، ستعرف دور كل من هذه الأدوات .
  • &lt;Response&gt; - <Response>. تضم العنصر أيضًا <الخطوات>. وتستدعي هذه الخطوات أيضًا السياسات المسؤولة عن معالجة النتيجة النهائية استجابة من نقطة النهاية المستهدفة (واجهة برمجة التطبيقات Google Elevation API).
  • &lt;HttpProxyConnection&gt; - يحدد هذا العنصر تفاصيل عن كيفية ربط التطبيقات بالخادم الوكيل لواجهة برمجة التطبيقات هذا، بما في ذلك <BasePath> الذي يحدد كيفية فسيتم استدعاء واجهة برمجة التطبيقات هذه.
  • &lt;RouteRule&gt;: يحدد هذا العنصر ما سيحدث على الفور. بعد معالجة رسائل الطلبات الواردة. وفي هذه الحالة، يتم استدعاء نقطة النهاية المستهدفة. سنناقش المزيد حول هذه الخطوة المهمة لاحقًا في هذا الموضوع.

إنشاء السياسات

تناقش الأقسام التالية كل سياسة من السياسات التي تتألف منها هذه السياسة. مثال.

إنشاء أول AssignMessage السياسة

تتضمن سياسة AssignMessage الأولى أدناه، ينشئ رسالة طلب سيتم إرسالها إلى نظام الترميز الجغرافي من Google خدمة ما.

لنبدأ برمز السياسة، ثم سنشرح عناصره بمزيد من التفصيل. في جلسة المعمل، تنزيل نموذج، يمكنك العثور على XML في الملف doc-samples/policy-mashup-cookbook/apiproxy/policies/GenerateGeocodingRequest.xml

<AssignMessage name="GenerateGeocodingRequest">
  <AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
  <Set>
    <QueryParams>
      <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
      <QueryParam name="region">{request.queryparam.country}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
    <Verb>GET</Verb>
  </Set>
  <!-- Set variables for use in the final response -->
  <AssignVariable>
    <Name>PostalCode</Name>
    <Ref>request.queryparam.postalcode</Ref>
  </AssignVariable>
  <AssignVariable>
    <Name>Country</Name>
    <Ref>request.queryparam.country</Ref>
  </AssignVariable>
</AssignMessage>

في ما يلي وصف موجز لعناصر هذه السياسة. يمكنك قراءة المزيد عن هذا الموضوع سياسة في تعيين سياسة الرسائل

  • <assignMessage name>: تسمية هذه السياسة الاسم هو يتم استخدامه عند الإشارة إلى السياسة في التدفق.
  • &lt;AssignTo&gt;: ينشئ متغيّرًا باسم GeocodingRequest. يغلف هذا المتغير كائن الطلب الذي سيتم إرساله إلى الخلفية بواسطة سياسة ServiceCallout
  • &lt;QueryParams&gt; - لضبط معلَمات طلب البحث اللازمة واجهة برمجة التطبيقات الخاصة بالخلفية. في هذه الحالة، تحتاج واجهة برمجة التطبيقات Geocoding API إلى معرفة الموقع، وهو ويتم التعبير عنها برمز بريدي ومعرّف البلد. يوفر مستخدم التطبيق هذه المعلومات، فإننا ببساطة نستخرجه هنا. تطلب واجهة برمجة التطبيقات المَعلمة sensor، وهي إما صواب أم خطأ، ونضع الرموز الثابتة على false هنا فقط.
  • &lt;Verb&gt; - في هذه الحالة، سنُجري طلب GET بسيطًا إلى واجهة برمجة التطبيقات.
  • &lt;AssignVariable&gt; - تخزِّن هذه المتغيرات القيم التي تمريره إلى واجهة برمجة التطبيقات. في هذا المثال، سيتم الوصول إلى المتغيّرات لاحقًا في الردّ وإعادته إلى العميل.

إرسال الطلب باستخدام ServiceCallout

الخطوة التالية في تسلسل إنشاء السياسة هي إنشاء سياسة ServiceCallout. تشير رسالة الأشكال البيانية ترسل سياسة ServiceCallout الواردة أدناه كائن الطلب الذي أنشأناه في سياسة assignMessage السابقة في خدمة الترميز الجغرافي من Google، وحفظ النتيجة في يسمى GeocodingResponse.

كما كان من قبل، لنلقِ نظرة على التعليمات البرمجية أولاً. وفي ما يلي شرح مفصل. يمكنك قراءة يمكنك الاطّلاع على مزيد من المعلومات عن هذه السياسة في مقالة وسيلة شرح الخدمة. . في نموذج التنزيل، يمكنك العثور على ملف XML هذا في الملف. doc-samples/policy-mashup-cookbook/apiproxy/policies/ExecuteGeocodingRequest.xml

<ServiceCallout name="ExecuteGeocodingRequest">
  <Request variable="GeocodingRequest"/>
  <Response>GeocodingResponse</Response>
  <HTTPTargetConnection>
    <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
  </HTTPTargetConnection>
</ServiceCallout>

في ما يلي وصف موجز لعناصر هذه السياسة.

  • &lt;ServiceCallout&gt; - كما هو الحال مع السياسة السابقة، تحتوي هذه السياسة على الاسم.
  • <Requestvariable> - هذا هو المتغير الذي تم إنشاؤه في سياسة AssignMessage. وهو يتضمن الطلب الذي ينتقل إلى واجهة برمجة التطبيقات الخلفية.
  • &lt;Response&gt; - يسمي هذا العنصر متغيرًا تكون الاستجابة فيه تخزين البيانات. كما ترى، سيتم الوصول إلى هذا المتغيّر لاحقًا من خلال OutputVariables. .
  • &lt;HTTPTargetConnection&gt;: لتحديد عنوان URL المستهدف للخلفية واجهة برمجة التطبيقات. في هذه الحالة، نحدِّد أن تعرض واجهة برمجة التطبيقات استجابة JSON.

لدينا الآن سياستان، إحداهما تحدد معلومات الطلب اللازمة لاستخدام واجهة برمجة التطبيقات Backend API (واجهة برمجة التطبيقات Geocoding من Google) وواجهة برمجة التطبيقات الثانية التي ترسل الطلب إلى واجهة برمجة التطبيقات الخلفية. بعد ذلك، سنتعامل مع الرد.

تحليل الرد باستخدام ExtractVariables

توفِّر سياسة استخراج المتغيّرات آلية بسيطة لتحليل المحتوى من رسالة رد تم الحصول عليها من خلال سياسة ServiceCallout. يمكن استخدام متغيّرات الاستخراج لتحليل JSON أو XML، أو يمكن استخدامه لاستخراج المحتوى من مسارات URI أو عناوين HTTP أو طلبات البحث ومعلمات النموذج.

في ما يلي قائمة بسياسة OutputVariables. يمكنك الاطّلاع على مزيد من المعلومات عن هذه السياسة في استخراج المتغيرات . في نموذج التنزيل، يمكنك العثور على ملف XML هذا في الملف. doc-samples/policy-mashup-cookbook/apiproxy/policies/ParseGeocodingResponse.xml

<ExtractVariables name="ParseGeocodingResponse">
  <Source>GeocodingResponse</Source>
  <VariablePrefix>geocoderesponse</VariablePrefix>
  <JSONPayload>
    <Variable name="latitude">
       <JSONPath>$.results[0].geometry.location.lat</JSONPath>
    </Variable>
    <Variable name="longitude">
       <JSONPath>$.results[0].geometry.location.lng</JSONPath>
    </Variable>
  </JSONPayload>
</ExtractVariables>

في ما يلي العناصر الرئيسية لسياسة PermissionVariable:

  • <استخراج المتغيّرات name>: مرة أخرى، يُستخدَم اسم السياسة للأغراض التالية: وأن يشير إلى السياسة عند استخدامها في التدفق.
  • &lt;Source&gt; - لتحديد متغير الاستجابة الذي أنشأناه في سياسة ServiceCallout. وهو المتغيّر الذي يتم منه استخراج البيانات من خلال هذه السياسة.
  • &lt;VariablePrefix&gt; - تحدد البادئة المتغيرة مساحة اسم ومتغيرات أخرى تم إنشاؤها في هذه السياسة. ويمكن أن تكون البادئة أي اسم، باستثناء البادئة المحجوزة التي تم تعريفها بواسطة Edge's المتغيرات المحددة مسبقًا.
  • &lt;JSONPayload&gt; - يسترد هذا العنصر بيانات الاستجابة التي تهمنا وتضعها في المتغيرات المسماة. في الواقع، تُرجع واجهة برمجة التطبيقات Geocoding API الكثير معلومات أكثر من خطوط الطول والعرض. ومع ذلك، هذه هي القيم الوحيدة التي نحتاج إليها لهذه العينة. يمكنك الاطّلاع على عرض كامل لملف JSON الذي تعرضه Geocoding API. في واجهة برمجة التطبيقات ذات الصلة. تكون قيم geometry.location.lat وgeometry.location.lng ببساطة اثنين من الحقول الكثيرة في كائن JSON المعروض.

قد لا يكون الأمر واضحًا، ولكن من المهم معرفة أنّ استخراجات متغيّرات تُنتج متغيّرَين المتغيرات التي تتكون أسماؤها من البادئة المتغيرة (georesponse) والرمز بأسماء المتغيّرات المحدّدة في السياسة. يتم تخزين هذه المتغيرات في سيكون الخادم الوكيل متاحًا للسياسات الأخرى ضمن مسار الخادم الوكيل نرى. والمتغيرات هي:

  • geocoderesponse.latitude
  • geocoderesponse.longitude

تم الانتهاء من معظم العمل الآن. لقد أنشأنا مزيجًا من ثلاث سياسات وطلب واجهة برمجة تطبيقات للخلفية، وتحليل بيانات JSON المعروضة. في الخطوات الأخيرة، سنقوم بتغذية البيانات من هذا الجزء من التدفق إلى سياسة AssignMessage أخرى، يمكنك طلب إضافة الواجهة الخلفية الثانية (واجهة برمجة التطبيقات Google Eliffation API)، وإرجاع البيانات التي تم دمجها إلى مطوّر التطبيق.

إنشاء الإجراء الثاني طلب عبر AssignMessage

تستخدم سياسة AssignMessage التالية المتغيّرات التي يتم إرجاعها من الواجهة الخلفية الأولى (التي تستخدم Google الترميز الجغرافي) التي خزّنها ووصلها في طلب موجَّه إلى واجهة برمجة التطبيقات الثانية (Google الارتفاع). كما هو موضح سابقًا، هذه المتغيرات هي georesponse.width. geocoderesponse.longitude.

في نموذج التنزيل، يمكنك العثور على ملف XML هذا في الملف. doc-samples/policy-mashup-cookbook/apiproxy/policies/AssignElevationParameters.xml

<AssignMessage name="AssignElevationParameters">
<Remove>
    <QueryParams>
      <QueryParam name="country"/>
      <QueryParam name="postalcode"/>
    </QueryParams>
  </Remove>
  <Set>
    <QueryParams>
      <QueryParam name="locations">{geocoderesponse.latitude},{geocoderesponse.longitude}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
  </Set>
</AssignMessage>

إذا قمت بفحص واجهة برمجة التطبيقات Google Elevation API، فستلاحظ أنها تتطلب معاملي طلب بحث. يُطلق على الاسم الأول اسم locations وقيمته هي خط العرض وخط الطول. (قيم مفصولة بفواصل). المعلمة الأخرى هي sensor، وهي مطلوبة ويجب أن تكون إما صواب أم خطأ. أهم شيء يجب ملاحظته في هذه المرحلة هو أن طلب التي ننشئها هنا لا تتطلب ServiceCallout. لا نحتاج إلى الاتصال بالثاني من واجهة برمجة التطبيقات ServiceCallout في هذه المرحلة لأنه يمكننا استدعاء واجهة برمجة التطبيقات الخلفية من واجهة برمجة تطبيقات الخادم الوكيل نقطة النهاية المستهدفة. إذا فكرت في الأمر، فلدينا كل البيانات التي نحتاج إليها لتسمية Google Elevations لا تتطلب رسالة الطلب التي تم إنشاؤها في هذه الخطوة وجود ServiceCallout، حيث يتم إنشاؤه لمسار الطلب الرئيسي، ولذا ستتم إعادة توجيهه ببساطة ProxyEndpoint إلى TargetEndpoint، بعد اتّباع قاعدة RouteRule التي تم ضبطها للخادم الوكيل لواجهة برمجة التطبيقات هذا تدير TargetEndpoint الاتصال بواجهة برمجة التطبيقات البعيدة. (تذكر أن عنوان URL يتم تحديد واجهة برمجة تطبيقات الارتفاع (HTTPConnection) من أجل نقطة النهاية المستهدفة. واجهة برمجة التطبيقات للارتفاعات التوثيق إذا كنت ترغب في معرفة المزيد. استعلامات QueryParams التي قمنا بتخزينها مسبقًا، لم تعُد هناك حاجة إلى country وpostalcode، لذلك أزلناهما. هنا.

توقف قصير: العودة إلى الخطوات

في هذه المرحلة، قد تتساءل عن سبب عدم إنشاء سياسة ServiceCallout أخرى. بعد الكل، أنشأنا رسالة أخرى. كيف يتم إرسال هذه الرسالة إلى الهدف، أي Google Eliffation API؟ تتوفر الإجابة في <RouteRule>. عنصر التدفق. &lt;RouteRule&gt; يحدد الإجراء المطلوب اتخاذه مع أي رسائل طلب متبقية بعد <Request> جزء من وتم تنفيذ التدفق. تشير هذه القاعدة إلى نقطة النهاية المستهدفة التي يحددها <RouteRule>. تخبر الخادم الوكيل لواجهة برمجة التطبيقات لإرسال الرسالة إلى http://maps.googleapis.com/maps/api/elevation/xml.

إذا نزّلت نموذج الخادم الوكيل لواجهة برمجة التطبيقات، يمكنك العثور على TargetProxy XML في الملف. doc-samples/policy-mashup-cookbook/apiproxy/targets/default.xml

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <!-- This is where we define the target. For this sample we just use a simple URL. -->
    <URL>http://maps.googleapis.com/maps/api/elevation/xml</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

كل ما نحتاج إليه الآن هو معالجة الرد من واجهة برمجة التطبيقات Google Elevation API تم.

تحويل الردّ من XML إلى JSON

في هذا المثال، يتم عرض الاستجابة من Google Elevation API بتنسيق XML. لـ "إضافية ورصيد دعونا نضيف سياسة أخرى إلى المركب لتحويل الاستجابة من XML إلى JSON.

يستخدم هذا المثال سياسة JavaScript المُسمّاة GenerateResponse، مع ملف موارد. الذي يحتوي على رمز JavaScript، وذلك لإجراء التحويل. الموضح أدناه هو تعريف سياسة GenerateResponse:

<Javascript name="GenerateResponse" timeout="10000">
  <ResourceURL>jsc://GenerateResponse.js</ResourceURL>
</Javascript>

يشتمل ملف المورد GenerateResponse.js على JavaScript المستخدم لتنفيذ تحويل. يمكنك رؤية هذه التعليمة البرمجية في الملف doc-samples/policy-mashup-cookbook/apiproxy/resources/JSC/GenerateResponse.js.

توفّر Apigee أيضًا سياسة جاهزة تُسمّى XMLToJSON لتحويل XML إلى JSON. يمكنك تعديل ProxyEndpoint لاستخدام سياسة xmltojson الموضَّحة أدناه بدلاً من ذلك. 

<XMLToJSON name="xmltojson">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

اختبار المثال

جرِّب تنزيل ونشر وتشغيل نموذج policy-mashup-cookbook، الذي يمكنك العثور عليه في مجلد نماذج المستندات في مستودع نماذج Apigee Edge في GitHub. العدل اتّبِع التعليمات الواردة في ملفّ README في مجلد "كتاب الطبخ في مزج السياسات". أو اتبع التعليمات الموجزة هنا: استخدام نماذج الخوادم الوكيلة لواجهة برمجة التطبيقات

للتلخيص، يمكنك استدعاء واجهة برمجة التطبيقات المركبة على النحو التالي. استبدِل {myorg} بـ اسم المؤسسة:

$ curl "http://{myorg}-test.apigee.net/policy-mashup-cookbook?country=us&postalcode=08008"

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

{  
   "country":"us",
   "postalcode":"08008",
   "elevation":{  
      "meters":0.5045232,
      "feet":1.6552599030345978
   },
   "location":{  
      "latitude":39.75007129999999,
      "longitude":-74.1357407
   }
}

ملخّص

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