طلبات التجميع

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

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

نظرة عامة

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

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

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

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

الحد الأقصى لعدد المكالمات في كل طلب مُجمَّع بـ 100 مكالمة. وإذا كنت بحاجة إلى إجراء استدعاءات أكثر من ذلك، فاستخدم طلبات مجمَّعة متعددة.

ملاحظة: يستخدم نظام التجميعي لواجهة برمجة التطبيقات Gmail API البنية نفسها التي يستخدمها نظام المعالجة المجمّعة لبيانات OData، ولكن تختلف المعنى.

ملاحظة: من المحتمل أن تؤدي أحجام الدُفعات الأكبر إلى تقييد المعدّل. لا يُنصح بإرسال دفعات أكبر من 50 طلبًا.

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

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

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

تنسيق الطلب المجمّع

الطلب المجمّع هو طلب HTTP عادي واحد يحتوي على عدة طلبات من واجهة برمجة التطبيقات Gmail API، وذلك باستخدام نوع المحتوى 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. ومع ذلك، تنطبق المفاهيم نفسها على Gmail API.

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

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