إرسال طلبات مجمّعة

يوضّح هذا المستند كيفية تجميع طلبات البيانات من واجهة برمجة التطبيقات معًا لتقليل عدد اتصالات HTTP التي يجب أن يجريها العميل.

يدور هذا المستند تحديدًا حول إجراء طلب مجمّع عن طريق إرسال طلب HTTP. بدلاً من ذلك، إذا كنت تستخدم مكتبة برامج Google لإنشاء طلب مجمّع، يُرجى الاطّلاع على مستندات مكتبة البرامج.

نظرة عامة

يؤدي كل اتصال HTTP يجريه العميل إلى قدر معيّن من النفقات العامة. تتيح واجهة برمجة تطبيقات إدارة تراخيص Enterprise التجميع للسماح للعميل بوضع العديد من طلبات البيانات من واجهة برمجة التطبيقات في طلب HTTP واحد.

في ما يلي أمثلة على الحالات التي قد تحتاج فيها إلى استخدام ميزة "تجميع الطلبات":

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

وفي كلتا الحالتَين، بدلاً من إرسال كل طلب بشكل منفصل، يمكنك تجميعها معًا في طلب HTTP واحد. يجب أن تنتقل جميع الطلبات الداخلية إلى Google API نفسها.

الحد المسموح به هو 1000 مكالمة في طلب مُجمَّع واحد. إذا كان عليك إجراء المزيد من المكالمات، استخدِم طلبات مجمّعة متعددة.

ملاحظة: يستخدم نظام الحِزم لواجهة برمجة التطبيقات Enterprise License Manager API بنية الجملة نفسها المستخدَمة في نظام المعالجة المجمّعة في OData، ولكن تختلف الدلالات.

تفاصيل الدفعة

يتألّف طلب الدفعة من طلبات متعددة للحصول على البيانات من واجهة برمجة التطبيقات يتم دمجها في طلب HTTP واحد، ويمكن إرساله إلى batchPath المحدّد في مستند استكشاف واجهة برمجة التطبيقات. المسار التلقائي هو /batch/api_name/api_version. يوضّح هذا القسم بنية الحِزم بالتفصيل، وسنقدّم مثالاً لاحقًا.

ملاحظة: تُحتسَب مجموعة من n طلبًا مجمّعة معًا ضمن حدّ الاستخدام على أنّها n طلبًا، وليس طلبًا واحدًا. يتم فصل الطلب المجمّع إلى مجموعة من الطلبات قبل معالجته.

تنسيق طلب الحزمة

الطلب المجمّع هو طلب HTTP عادي واحد يحتوي على عدة طلبات للحصول على البيانات من واجهة برمجة التطبيقات لإدارة تراخيص Enterprise، باستخدام نوع المحتوى multipart/mixed. ضمن طلب HTTP الرئيسي هذا، يحتوي كل جزء على طلب HTTP مُدمَج.

يبدأ كل جزء بعنوان HTTP يتضمّن Content-Type: application/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. ومع ذلك، تنطبق المفاهيم نفسها على واجهة برمجة التطبيقات لإدارة تراخيص Enterprise.

مثال على طلب مجمّع

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:[e-mail]>

GET /farm/v1/animals/pony

--batch_foobarbaz
Content-Type: application/http
Content-ID: <item2:[e-mail]>

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:[e-mail]>

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:[e-mail]>

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:[e-mail]>

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:[e-mail]>

HTTP/1.1 304 Not Modified
ETag: "etag/animals"

--batch_foobarbaz--