يوضّح هذا المستند كيفية تجميع طلبات البيانات من واجهة برمجة التطبيقات معًا لتقليل عدد اتصالات HTTP التي يجب أن يجريها العميل.
يتناول هذا المستند تحديدًا تقديم طلب مجمّع من خلال إرسال طلب HTTP. بدلاً من ذلك، إذا كنت تستخدم مكتبة برامج Google لإنشاء طلب مجمّع، يُرجى الاطّلاع على مستندات مكتبة البرامج.
نظرة عامة
ينتج عن كل اتصال HTTP للعميل مقدار معين من النفقات العامة. تتيح واجهة برمجة التطبيقات في Google Search Console إمكانية تجميع طلبات البيانات، وذلك للسماح لعميلك بوضع العديد من طلبات البيانات من واجهة برمجة التطبيقات في طلب HTTP واحد.
في ما يلي أمثلة على الحالات التي قد تحتاج فيها إلى استخدام ميزة "تجميع الطلبات":
- لقد بدأت للتو استخدام واجهة برمجة التطبيقات ولديك الكثير من البيانات لتحميلها.
- أجرى مستخدم تغييرات على البيانات عندما كان تطبيقك بلا اتصال بالإنترنت، لذا يحتاج تطبيقك إلى مزامنة بياناته المحلية مع الخادم من خلال إرسال الكثير من عمليات التعديل والحذف.
وفي كلتا الحالتَين، بدلاً من إرسال كل طلب بشكل منفصل، يمكنك تجميعها معًا في طلب HTTP واحد. يجب أن تنتقل جميع الطلبات الداخلية إلى Google API نفسها.
يمكنك إجراء 1,000 مكالمة كحد أقصى في طلب دفعة واحدة. إذا كان عليك إجراء المزيد من المكالمات، استخدِم طلبات مجمّعة متعددة.
ملاحظة: يستخدم نظام الدفعات لواجهة برمجة التطبيقات Google Search Console بنية الجملة نفسها المستخدَمة في نظام المعالجة المجمّعة في OData، ولكنّ الدلالات تختلف.
تفاصيل الدفعة
يتكون الطلب المجمّع من طلبات بيانات متعددة من واجهة برمجة التطبيقات مدمَجة في طلب HTTP واحد، والذي يمكن إرساله إلى batchPath
المحدَّد في مستند استكشاف واجهة برمجة التطبيقات. المسار التلقائي هو /batch/api_name/api_version
. ويصف هذا القسم بنية الدُفعة بالتفصيل، ويمكنك الاطّلاع لاحقًا على مثال.
ملاحظة: تُحتسَب مجموعة من n طلبًا مجمّعة معًا ضمن حدّ الاستخدام على أنّها n طلبًا، وليس طلبًا واحدًا. يتم تقسيم الطلب المجمّع إلى مجموعة من الطلبات قبل معالجته.
تنسيق طلب الحزمة
الطلب المجمّع هو طلب HTTP عادي واحد يحتوي على عدّة طلبات بحث في Google Search Console API، باستخدام نوع المحتوى multipart/mixed
. ضمن طلب HTTP الرئيسي هذا، يحتوي كل جزء على طلب HTTP مُدمَج.
يبدأ كل جزء برأس Content-Type: application/http
HTTP الخاص به. ويمكن أن يحتوي أيضًا على عنوان Content-ID
اختياري. ومع ذلك، تهدف عناوين الأجزاء إلى وضع علامة على بداية الجزء فقط، وهي منفصلة عن الطلب المُدمَج. بعد أن يفكّ الخادم طلب الحزمة إلى طلبات منفصلة، يتم تجاهل عناوين الأجزاء.
النص الأساسي لكل جزء هو طلب HTTP كامل، يضم فعل وعنوان URL ورؤوس ونص. يجب أن يحتوي طلب HTTP على جزء المسار من عنوان URL فقط، ولا يُسمح بعناوين URL الكاملة في الطلبات المجمّعة.
تنطبق عناوين HTTP لطلب الدفعة الخارجي، باستثناء عناوين Content-
مثل Content-Type
، على كل طلب في الدفعة. إذا حدّدت عنوان HTTP معيّنًا في كلّ من الطلب الخارجي وطلب فردي، ستحلّ قيمة عنوان الطلب الفردي محلّ قيمة عنوان طلب الحزمة الخارجي. لا تنطبق عناوين مكالمة فردية إلا على تلك المكالمة.
على سبيل المثال، إذا قدّمت رأس "تفويض" لمكالمة معيّنة، ينطبق هذا الرأس على هذه المكالمة فقط. إذا قدّمت رأس "تفويض" للطلب الخارجي، ينطبق هذا الرأس على جميع الطلبات الفردية ما لم يتم إلغاؤه باستخدام رؤوس "تفويض" خاصة بها.
عندما يتلقّى الخادم الطلب المجمّع، يطبّق مَعلمات طلب البحث والروابط (حسب الاقتضاء) على كل جزء، ثم يتعامل مع كل جزء كما لو كان طلب HTTP منفصلاً.
الردّ على طلب دفعة
استجابة الخادم هي استجابة HTTP عادية واحدة بنوع محتوى multipart/mixed
، وكل جزء منها هو استجابة لأحد الطلبات في الطلب المجمّع بالترتيب نفسه للطلبات.
مثل الأجزاء في الطلب، يحتوي كل جزء من أجزاء الاستجابة على استجابة HTTP كاملة، بما في ذلك رمز الحالة والرؤوس والنص. وكما هو الحال مع الأجزاء في الطلب، يسبق كل جزء من الاستجابة عنوان Content-Type
يشير إلى بداية الجزء.
إذا كان جزء معيّن من الطلب يتضمّن عنوان Content-ID
، سيتضمّن الجزء المقابل من الاستجابة عنوان Content-ID
مطابقًا، مع القيمة الأصلية التي تسبقها السلسلة response-
، كما هو موضّح في المثال التالي.
ملاحظة: قد يُجري الخادم مكالماتك بأي ترتيب. لا تعتمد على تنفيذها بالترتيب الذي حدّدته. إذا كنت تريد التأكّد من إجراء مكالمتَين بترتيب معيّن، لا يمكنك إرسالهما في طلب واحد، بل أرسِل المكالمة الأولى بمفردها، ثم انتظِر الردّ عليها قبل إرسال المكالمة الثانية.
مثال
يعرض المثال التالي استخدام ميزة تجميع الطلبات مع واجهة برمجة تطبيقات تجريبية عامة (خيالية) تُسمى Farm API. تنطبق المفاهيم نفسها على واجهة برمجة التطبيقات في Google Search Console.
مثال على طلب مجمّع
POST /batch/farm/v1 HTTP/1.1 Authorization: Bearer your_auth_token Host: www.googleapis.com Content-Type: multipart/mixed; boundary=batch_foobarbaz Content-Length: total_content_length --batch_foobarbaz Content-Type: application/http Content-ID: <item1:12930812@barnyard.example.com> GET /farm/v1/animals/pony --batch_foobarbaz Content-Type: application/http Content-ID: <item2:12930812@barnyard.example.com> PUT /farm/v1/animals/sheep Content-Type: application/json Content-Length: part_content_length If-Match: "etag/sheep" { "animalName": "sheep", "animalAge": "5" "peltColor": "green", } --batch_foobarbaz Content-Type: application/http Content-ID: <item3:12930812@barnyard.example.com> GET /farm/v1/animals If-None-Match: "etag/animals" --batch_foobarbaz--
مثال على استجابة الحِزم
هذه هي الاستجابة للطلب النموذجي في القسم السابق.
HTTP/1.1 200 Content-Length: response_total_content_length Content-Type: multipart/mixed; boundary=batch_foobarbaz --batch_foobarbaz Content-Type: application/http Content-ID: <response-item1:12930812@barnyard.example.com> HTTP/1.1 200 OK Content-Type application/json Content-Length: response_part_1_content_length ETag: "etag/pony" { "kind": "farm#animal", "etag": "etag/pony", "selfLink": "/farm/v1/animals/pony", "animalName": "pony", "animalAge": 34, "peltColor": "white" } --batch_foobarbaz Content-Type: application/http Content-ID: <response-item2:12930812@barnyard.example.com> HTTP/1.1 200 OK Content-Type: application/json Content-Length: response_part_2_content_length ETag: "etag/sheep" { "kind": "farm#animal", "etag": "etag/sheep", "selfLink": "/farm/v1/animals/sheep", "animalName": "sheep", "animalAge": 5, "peltColor": "green" } --batch_foobarbaz Content-Type: application/http Content-ID: <response-item3:12930812@barnyard.example.com> HTTP/1.1 304 Not Modified ETag: "etag/animals" --batch_foobarbaz--