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

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

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

نظرة عامة

ينتج عن كل اتصال HTTP للعميل مقدار معين من النفقات العامة. تدعم واجهة برمجة التطبيقات Google Calendar API التجميع للسماح للعميل بوضع العديد من طلبات البيانات من واجهة برمجة التطبيقات في طلب HTTP واحد.

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

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

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

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

ملاحظة: يستخدم النظام المجمّع لواجهة برمجة تطبيقات "تقويم Google" البنية نفسها التي يستخدمها نظام معالجة دُفعات OData، ولكن تختلف الدلالات التي تم رصدها.

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

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

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

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

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