ويتناول هذا المستند بعض الأساليب التي يمكنك استخدامها لتحسين أداء تطبيقك. في بعض الحالات، يتم استخدام أمثلة من واجهات برمجة تطبيقات أخرى أو واجهات برمجة تطبيقات عامة لتوضيح الأفكار المعروضة. ومع ذلك، تنطبق المفاهيم نفسها على واجهة برمجة التطبيقات Android Over The Air API.
الضغط باستخدام 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، وتبقى حالة المورد بدون تغيير. على سبيل المثال، إذا حاولت حذف قيمة حقل مطلوب، سيعرض الخادم خطأ.
أسلوب بديل عند عدم توفّر فعل HTTP PATCH
إذا كان جدار الحماية لا يسمح بطلبات HTTP PATCH، يمكنك تنفيذ طلب HTTP POST وضبط عنوان الإلغاء على PATCH، كما هو موضّح أدناه:
POST https://www.googleapis.com/... X-HTTP-Method-Override: PATCH ...
الفرق بين التصحيح والتحديث
من الناحية العملية، عند إرسال بيانات لطلب تعديل يستخدم فعل HTTP PUT، ما عليك سوى إرسال الحقول المطلوبة أو الاختيارية فقط. وفي حال إرسال قيم للحقول التي يضبطها الخادم، سيتم تجاهلها. على الرغم من أنّ هذا قد يبدو كطريقة أخرى لإجراء تعديل جزئي، إلا أنّ هذا النهج له بعض القيود. في ما يتعلّق بالتعديلات التي تستخدِم فعل HTTP PUT، يتعذّر إكمال الطلب في حال عدم تقديم المَعلمات المطلوبة، ويتم محو البيانات التي تم ضبطها سابقًا في حال عدم تقديم المَعلمات الاختيارية.
لهذا السبب، من الأفضل استخدام التصحيح. لا تقدّم سوى بيانات الحقول التي تريد تغييرها، ولا يتم محو الحقول التي تحذفها. يحدث الاستثناء الوحيد لهذه القاعدة مع العناصر أو الصفائف المتكررة: إذا حذفتها جميعًا، فستظل كما هي؛ في حال توفير أيٍّ منها، يتمّ استبدال المجموعة الكاملة بالمجموعة التي تقدّمها.