يعرض هذا المستند بعض الأساليب التي يمكنك استخدامها لتحسين أداء تطبيقك. في بعض الحالات، قد نستخدم أمثلة من واجهات برمجة تطبيقات أخرى أو واجهات عامة لتوضيح الأفكار المطروحة. ومع ذلك، تنطبق المفاهيم نفسها على واجهة برمجة التطبيقات Android Over The Air.
ضغط البيانات باستخدام gzip
من خلال ضغط البيانات باستخدام gzip، يمكنك بسهولة تقليل معدّل نقل البيانات المطلوب لكل طلب. وعلى الرغم من أنّ هذه العملية تتطلب وقتًا إضافيًا لفك ضغط النتائج من خلال وحدة المعالجة المركزية، هي تجدي نفعًا لأنّها تحدّ من تكاليف حركة بيانات الشبكة.
للحصول على استجابة مرمّزة باستخدام gzip، يجب تنفيذ خطوتَين: تعيين عنوان Accept-Encoding وتعديل وكيل المستخدم ليتضمّن السلسلة gzip. وفي ما يلي مثال على عناوين HTTP تمت صياغتها بشكل صحيح لتمكين ضغط البيانات باستخدام gzip:
Accept-Encoding: gzip User-Agent: my program (gzip)
استخدام موارد جزئية
من الطرق الأخرى الفعالة لتحسين أداء طلبات البيانات من واجهة برمجة التطبيقات هي أن ترسل وتتلقّى الجزء الذي تحتاجه من البيانات فقط. يتيح ذلك لتطبيقك تجنّب نقل ومعالجة وتخزين الحقول غير الضرورية، وبالتالي يساعد على استخدام الموارد، مثل الشبكة ووحدة المعالجة المركزية والذاكرة، بكفاءة أكبر.
هناك نوعان من الطلبات الجزئية:
- الاستجابة الجزئية: طلب تحدّد فيه الحقول التي تريد تضمينها في الاستجابة (استخدِم مَعلمة الطلب
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، يتعذّر تنفيذ الطلب إذا لم تقدّم المَعلمات المطلوبة، كما أنّه يمحو البيانات التي تم ضبطها سابقًا إذا لم تقدّم المَعلمات الاختيارية.
ولهذا السبب، من الأفضل استخدام التصحيح. عليك تقديم البيانات فقط للحقول التي تريد تغييرها، ولن تتم إزالة الحقول التي تحذفها. الاستثناء الوحيد لهذه القاعدة هو العناصر أو المصفوفات المتكرّرة: إذا حذفتها كلها، ستبقى كما هي، وإذا قدّمت أيًا منها، سيتم استبدال المجموعة بأكملها بالمجموعة التي تقدّمها.