يتناول هذا المستند بعض الأساليب التي يمكنك استخدامها لتحسين أداء تطبيقك. في بعض الحالات، يتم استخدام أمثلة من واجهات برمجة تطبيقات أخرى أو واجهات برمجة تطبيقات عامة لتوضيح الأفكار المقدمة. في المقابل، تنطبق المفاهيم نفسها على واجهة برمجة تطبيقات Android Over The Air.
الضغط باستخدام gzip
هناك طريقة سهلة وملائمة لتقليل معدل نقل البيانات المطلوب لكل طلب، وهي تمكين ضغط gzip. وعلى الرغم من أن هذا الأمر يتطلب وقتًا إضافيًا لوحدة المعالجة المركزية لفك ضغط النتائج، فإن المفاضلة مع تكاليف الشبكة عادة ما تجعل الأمر مفيدًا للغاية.
لتلقّي استجابة بترميز gzip، عليك تنفيذ أمرَين: ضبط عنوان Accept-Encoding، وتعديل وكيل المستخدم الخاص بك لكي يتضمن السلسلة gzip. في ما يلي مثال على عناوين HTTP تم تشكيلها بشكل صحيح لتفعيل ضغط gzip:
Accept-Encoding: gzip User-Agent: my program (gzip)
العمل على الموارد الجزئية
هناك طريقة أخرى لتحسين أداء طلبات البيانات من واجهة برمجة التطبيقات، وهي إرسال جزء من البيانات التي تهتم بها فقط وتلقّيها. يسمح هذا لتطبيقك بتجنب نقل الحقول غير الضرورية وتحليلها وتخزينها، كي يتمكن من استخدام الموارد بما في ذلك الشبكة ووحدة المعالجة المركزية (CPU) والذاكرة بكفاءة أكبر.
هناك نوعان من الطلبات الجزئية:
- الاستجابة الجزئية: طلب تحدد من خلاله الحقول التي سيتم تضمينها في الرد (استخدم معلمة الطلب
fields). - تصحيح: طلب تحديث يتم من خلاله إرسال الحقول التي تريد تغييرها فقط (استخدم فعل HTTP
PATCH).
تتوفر في الأقسام التالية المزيد من التفاصيل حول تقديم طلبات جزئية.
ردّ جزئي
وبشكل افتراضي، يرسل الخادم التمثيل الكامل للمورد بعد معالجة الطلبات. للحصول على أداء أفضل، يمكنك أن تطلب من الخادم إرسال الحقول التي تحتاجها فقط والحصول على رد جزئي بدلاً من ذلك.
لطلب استجابة جزئية، يمكنك استخدام مَعلمة الطلب fields لتحديد الحقول التي تريد عرضها. يمكنك استخدام هذه المَعلمة مع أي طلب يعرض بيانات الاستجابة.
يُرجى العِلم أنّ المَعلمة fields تؤثر فقط في بيانات الاستجابة، ولا تؤثر في البيانات التي تحتاج إلى إرسالها، في حال توفّرها. لتقليل مقدار البيانات التي ترسلها عند تعديل الموارد، استخدِم طلب تصحيح.
مثال
رمز تصحيح (تحديث جزئي)
يمكنك أيضًا تجنب إرسال بيانات غير ضرورية عند تعديل الموارد. لإرسال البيانات المعدّلة للحقول المحدّدة التي تريد تغييرها فقط، استخدِم فعل HTTP PATCH. دلالات التصحيح الموضحة في هذا المستند مختلفة (وأبسط) عما كانت عليه في تطبيق GData القديم للتحديث الجزئي.
يوضح المثال المختصر أدناه كيف يؤدي استخدام رمز التصحيح إلى تقليل البيانات التي تحتاج إلى إرسالها لإجراء تحديث بسيط.
مثال
معالجة الاستجابة لإرسال رمز تصحيح
بعد معالجة طلب تصحيح صالح، تعرض واجهة برمجة التطبيقات رمز استجابة HTTP 200 OK مع التمثيل الكامل للمورد المعدّل. في حال استخدام علامات ETag من خلال واجهة برمجة التطبيقات، يعدّل الخادم قيم ETag عندما يعالج طلب تصحيح بنجاح، تمامًا كما يفعل PUT.
يعرض طلب حزمة التصحيح تمثيل المورد بأكمله ما لم تستخدم المعلمة fields لتقليل كمية البيانات التي يعرضها.
إذا أدى طلب التصحيح إلى حالة مورد جديدة غير صالحة من ناحية البنية أو دلاليًا، يعرض الخادم رمز حالة HTTP 400 Bad Request أو 422 Unprocessable Entity، وتظل حالة المورد بدون تغيير. على سبيل المثال، إذا حاولت حذف قيمة حقل مطلوب، سيعرض الخادم خطأ.
التدوين البديل عندما يكون فعل PATCH HTTP غير معتمد
في حال كان الجدار الناري لا يسمح بطلبات HTTP PATCH، يمكنك تنفيذ طلب HTTP POST وضبط عنوان الإلغاء على PATCH، كما هو موضّح أدناه:
POST https://www.googleapis.com/... X-HTTP-Method-Override: PATCH ...
الفرق بين التصحيح والتحديث
من الناحية العملية، عندما ترسل بيانات لطلب تحديث يستخدم فعل HTTP PUT، ما عليك سوى إرسال تلك الحقول التي تكون مطلوبة أو اختيارية. وإذا أرسلت قيم للحقول التي ضبطها الخادم، سيتم تجاهلها. على الرغم من أن هذه الطريقة قد تبدو وكأنها طريقة أخرى لإجراء تحديث جزئي، إلا أن هذا الأسلوب ينطوي على بعض القيود. في حال استخدام التحديثات التي تستخدم فعل HTTP PUT، يتعذّر تنفيذ الطلب في حال عدم توفير المَعلمات المطلوبة، كما أنّه يمحو البيانات التي تم ضبطها مسبقًا في حال عدم توفير مَعلمات اختيارية.
يكون استخدام رمز التصحيح لهذا السبب أكثر أمانًا. ما عليك سوى تقديم بيانات للحقول التي تريد تغييرها فقط، ولا يتم محو الحقول التي تحذفها. الاستثناء الوحيد لهذه القاعدة يحدث مع العناصر أو الصفائف المتكررة: فإذا حذفت جميعها، تظل كما هي، وفي حال تقديم أي منها، يتم استبدال المجموعة بالكامل بالمجموعة التي تقدمها.