الطلبات المجمّعة

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

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

نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

يبدأ كل جزء Content-Type: application/http ببروتوكول HTTP الخاص به. يمكن أن يحتوي أيضًا على Content-ID عنوان اختياري. ومع ذلك، فإنّ عناوين الأجزاء موجودة فقط لتحديد بداية الجزء، وهي منفصلة عن الطلب المتداخل. بعد أن يفك الخادم حزمة الطلبات إلى طلبات منفصلة، يتم تجاهل عناوين الأجزاء.

يمثّل نص كل جزء طلب HTTP كاملاً، مع ما يخصه من فعل وعنوان URL ورؤوس ونص. يجب أن يحتوي طلب HTTP على جزء المسار فقط من عنوان URL، ولا يُسمح باستخدام عناوين URL الكاملة في الطلبات المجمّعة.

تنطبق عناوين HTTP لطلب الدفعة الخارجي، باستثناء عناوين Content- مثل Content-Type، على كل طلب في الدفعة. إذا حدّدت عنوان HTTP معيّنًا في كلّ من الطلب الخارجي والمكالمة الفردية، ستتجاوز قيمة عنوان المكالمة الفردية قيمة عنوان طلب الدفعة الخارجي. تنطبق العناوين الخاصة بمكالمة فردية على تلك المكالمة فقط.

على سبيل المثال، إذا قدّمت عنوان Authorization لمكالمة معيّنة، سيتم تطبيق هذا العنوان على هذه المكالمة فقط. إذا قدّمت عنوان Authorization للطلب الخارجي، سينطبق هذا العنوان على جميع الطلبات الفردية ما لم يتم تجاوزه بعناوين Authorization خاصة بها.

عندما يتلقّى الخادم الطلب المجمّع، يطبّق مَعلمات طلب البحث والرؤوس (حسب الاقتضاء) الخاصة بالطلب الخارجي على كل جزء، ثم يعامل كل جزء كما لو كان طلب 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: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--