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

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

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

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

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

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

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

يستخدم المثال الذي تمت مناقشته هنا تركيب السياسات لمزج البيانات من واجهتَي برمجة تطبيقات منفصلَين متاحَين للجميع:

  • واجهة برمجة التطبيقات للترميز الجغرافي من Google: تحوِّل واجهة برمجة التطبيقات هذه العناوين (مثل "1600 Amphitheatre Parkway, Mountain View, CA") إلى إحداثيات جغرافية (مثل خط العرض 37.423021 وخط الطول -122.083739).
  • واجهة برمجة التطبيقات للارتفاعات العليا من Google: توفر واجهة برمجة التطبيقات هذه واجهة بسيطة للاستعلام عن المواقع على الأرض للحصول على بيانات المسقط الرأسي. في هذا المثال، سيتم استخدام الإحداثيات التي تم إرجاعها من واجهة برمجة التطبيقات للترميز الجغرافي كإدخال في واجهة برمجة التطبيقات هذه.

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

$ 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>

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

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

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

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

إنشاء سياسة 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> - أدخِل اسمًا لهذه السياسة. يُستخدم الاسم عند الإشارة إلى السياسة في تدفق.
  • <AssignTo> - تنشئ متغيرًا مُسمّى يسمى GeocodingRequest. ويضم هذا المتغيّر كائن الطلب الذي سيتم إرساله إلى الخلفية من خلال سياسة ServiceCallout.
  • <QueryParams> - لضبط معلَمات طلب البحث التي يحتاجها طلب البحث من واجهة برمجة التطبيقات الخلفية. في هذه الحالة، تحتاج واجهة برمجة تطبيقات الترميز الجغرافي إلى معرفة الموقع الجغرافي الذي يتم التعبير عنه برمز بريدي ومعرّف بلد. يوفّر مستخدم التطبيق هذه المعلومات، ونحن نستخرجها هنا. تتطلّب واجهة برمجة التطبيقات المعلَمة sensor وهي صحيحة أو غير صحيحة، ونحن نطبّقها على القيمة false هنا.
  • <Verb>: في هذه الحالة، نُجري طلب GET بسيطًا إلى واجهة برمجة التطبيقات.
  • <AssignVariable> - تخزِّن هذه المتغيرات القيم التي نمرّرها إلى واجهة برمجة التطبيقات. في هذا المثال، سيتم الوصول إلى المتغيّرات لاحقًا في الاستجابة التي يتم عرضها للعميل.

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

تتمثّل الخطوة التالية في تسلسل إنشاء السياسة في إنشاء سياسة ServiceCallout. ترسِل سياسة ServiceCallout المدرَجة أدناه كائن الطلب الذي أنشأناه في سياسة AssignMessage السابقة إلى خدمة Google Geocoding وتحفظ النتيجة في متغيّر يُسمى 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>

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

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

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

تحليل الاستجابة باستخدام snippetVariables

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

في ما يلي قائمة سياسة استخراج المتغيرات. يمكنك الاطّلاع على مزيد من المعلومات عن هذه السياسة في سياسة استخراج المتغيّرات. في نموذج التنزيل، يمكنك العثور على ملف 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>

العناصر الأساسية لسياسة استخراجVariable هي:

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

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

  • geocoderesponse.latitude
  • geocoderesponse.longitude

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

إنشاء الطلب الثاني باستخدام AssignMessage

تستخدم سياسة AssignMessage التالية المتغيرات التي تم إرجاعها من الواجهة الخلفية الأولى (Google Geocoding) التي خزّنناها، وتضيفها إلى طلب مخصّص لواجهة برمجة التطبيقات الثانية (Google Elevation). كما أشرنا سابقًا، هاتان المتغيرات هما radiusresponse.radius وradiusresponse.radius.

في نموذج التنزيل، يمكنك العثور على ملف 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، ستلاحظ أنّها تتطلب مَعلمتَي طلب بحث. تُسمى الأولى locations وقيمتها هي خط العرض وخط الطول (قيم مفصولة بفواصل). المعلمة الأخرى هي sensor، وهي مطلوبة ويجب أن تكون صحيحة أو خاطئة. وأهم شيء يجب ملاحظته في هذه المرحلة هو أنّ رسالة الطلب التي ننشئها هنا لا تتطلب "وسيلة شرح خدمة". ولسنا بحاجة إلى استدعاء واجهة برمجة التطبيقات الثانية من ServiceCallout في هذه المرحلة لأنه يمكننا استدعاء واجهة برمجة التطبيقات الخلفية من TargetEndpoint للخادم الوكيل. إذا فكرت في الأمر، لدينا جميع البيانات التي نحتاجها لاستدعاء واجهة برمجة تطبيقات Google للارتفاعات. لا تتطلب رسالة الطلب التي تم إنشاؤها في هذه الخطوة استخدام طريقة عرض الخدمة، لأنّ الطلب تم إنشاؤه لمسار الطلب الرئيسي، وبالتالي ستتم إعادة توجيهه من خلال ProxyEndpoint إلى TargetEndpoint، وفقًا لقاعدة Route التي تم إعدادها للخادم الوكيل لواجهة برمجة التطبيقات هذا. تدير TargetEndpoint الاتصال بواجهة برمجة التطبيقات البعيدة. (تذكَّر أنّ عنوان URL الخاص بواجهة برمجة تطبيقات تبرُز يتم تحديده في HTTPConnection لـ TargetEndpoint. يمكنك الحصول على معلومات حول Elevation API إذا أردت معرفة المزيد من المعلومات. لن نحتاج بعد الآن إلى مَعلمات QueryParams التي خزّنناها سابقًا، country وpostalcode، وبالتالي نُزيلها هنا.

توقف قصير: العودة إلى سير العمل

في هذه المرحلة، قد تتساءل لماذا لم ننشئ سياسة أخرى لوسيلة الشرح للخدمة. في النهاية، لقد أنشأنا رسالة أخرى. كيف يتم إرسال هذه الرسالة إلى الهدف، أي واجهة برمجة التطبيقات Google Elevation API؟ والإجابة هي في العنصر <RouteRule> للتدفق. يحدد <RouteRule> ما يجب فعله بأي رسائل طلب متبقية بعد تنفيذ جزء <Request> من التدفق. تطلب ميزة TargetEndpoint المُحدّدة من خلال <RouteRequest> هذا مع الخادم الوكيل لواجهة برمجة التطبيقات تسليم الرسالة إلى 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 في مجلد Policy-mashup-cookbook. أو اتّبِع التعليمات الموجزة هنا: استخدام نماذج الخوادم الوكيلة لواجهة برمجة التطبيقات.

للتلخيص، يمكنك استدعاء واجهة برمجة التطبيقات المركّبة على النحو التالي. استبدِل {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
   }
}

ملخّص

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