تصميم REST APIs قابلة للتوسّع لخوادم تطبيقات الموبايل

حين يحصل تطبيق على إشادة في App Store أو ينتشر فجأة مساء يوم جمعة في الرياض، فإن الـ backend إما أن يصمد أو ينهار. لا يوجد حل وسط أمام المستخدمين. والفرق بين تطبيق ينجو من نجاحه وآخر ينهار تحت ضغطه يعود غالبًا إلى قرارات اتُّخذت قبل أشهر، عند تصميم الـ REST API لأول مرة.

الـ backend الخاص بالموبايل ليس مجرد backend للويب مع هاتف أمامه. فالهواتف تعاني من شبكات متقطعة، وبطارية محدودة، وباقات بيانات مكلفة، ومستخدمين يغادرون التطبيق فور أن تتأخر الشاشة في الظهور. وتصميم REST API يناسب هذا الواقع يعني التفكير في scalability وحجم البيانات والأعطال قبل أن تظهر مشكلة الحجم بوقت طويل.

لماذا الـ Backend للموبايل لعبة مختلفة

المتصفح يجلس على شبكة WiFi مستقرة في معظم الوقت. أما الهاتف فيتنقل بين 5G وشبكة 3G مزدحمة وWiFi فندق ومصاعد بلا إشارة، وأحيانًا خلال الجلسة الواحدة. على الـ API أن يفترض الأسوأ دائمًا.

وهذا يغيّر طريقة تصميم الـ endpoints:

• كل رحلة ذهاب وإياب مكلفة. كل طلب على شبكة موبايل بطيئة قد يضيف مئات الميلي ثانية. والتطبيق الذي يحتاج إلى خمسة طلبات متتالية لعرض شاشة واحدة سيبدو معطّلًا حتى لو كان كل endpoint سريعًا تقنيًا.
• حجم البيانات يكلّف مالًا وبطارية. إرسال استجابة JSON بحجم 2 ميجابايت تحوي حقولًا لا يستخدمها التطبيق يستنزف باقة البيانات ويجبر الجهاز على معالجة أكثر مما يلزم.
• إعادة المحاولة أمر مضمون. طلبات الموبايل تفشل ويُعاد إرسالها باستمرار. وإن لم يكن الـ API آمنًا عند استدعائه مرتين، فستنشئ طلبات مكرّرة، وخصومات مزدوجة، وتذاكر دعم غاضبة.

تصميم API جيد للموبايل يبدأ من هذه القيود بدلًا من معاملتها كحالات استثنائية.

تصميم Endpoints قابلة للتوسّع

الـ scalability ليست مجرد إضافة خوادم. فالـ REST API المُحكم البنية يقلّل الحمل الذي يولّده كل مستخدم، وهذا أرخص بكثير من امتصاص ذلك الحمل بمزيد من البنية التحتية.

شكّل الاستجابات حول الشاشات لا حول الجداول

من الأخطاء الشائعة كشف بنية قاعدة البيانات مباشرة عبر الـ API: endpoint لكل جدول، ويتولى التطبيق تجميع كل شيء. وهذا يجبر عميل الموبايل على إجراء طلبات كثيرة، ويسرّب نموذجك الداخلي إلى الخارج.

بدلًا من ذلك، صمّم الـ endpoints حول ما تحتاجه الشاشة فعلًا. فشاشة تفاصيل المنتج قد تحتاج إلى المنتج، وملخص التقييمات، وحالة التوافر. endpoint واحد مُحكم يعيد هذا تحديدًا أفضل من ثلاثة عامة. ويمكنك أن تبقى ملتزمًا بمبادئ REST مع كونك واعيًا بما يعيده كل resource.

قسّم على صفحات كل ما ينمو

أي قائمة قابلة للنمو مع الوقت، مثل الطلبات أو الرسائل أو الإشعارات أو عناصر التغذية، يجب تقسيمها على صفحات من اليوم الأول. والـ pagination القائم على cursor أفضل عمومًا من المعتمد على offset في الموبايل، لأنه يبقى صحيحًا عند إدراج عناصر جديدة أثناء تمرير المستخدم للقائمة. وإعادة عشرة آلاف سجل "احتياطًا" هي أسرع طريقة لجعل التطبيق بطيئًا واستهلاك الذاكرة.

دع العملاء يطلبون أقل

ادعم الاستجابات الجزئية عبر اختيار الحقول أو توفير نسخ خفيفة ومفصّلة من الـ resource. فشاشة القائمة نادرًا ما تحتاج الكائن الكامل الذي تحتاجه شاشة التفاصيل. ومنح العملاء وسيلة لطلب حمولة أصغر يحسّن السرعة المُدركة مباشرة ويقلّل استهلاك الشبكة عبر ملايين الطلبات.

البناء مع توقّع الفشل وإعادة المحاولة

في الموبايل، الفشل هو الحالة الطبيعية لا الاستثناء. والـ backend القابل للتوسّع يتعامل معه على هذا الأساس.

• اجعل عمليات الكتابة idempotent. اقبل مفتاح idempotency يولّده العميل في الطلبات التي تنشئ بيانات أو تعدّلها. فإن وصل الطلب نفسه مرتين بسبب تعثّر الشبكة، يتعرّف الخادم على المفتاح ويعيد النتيجة الأصلية بدل تنفيذ العملية مجددًا. هذا النمط وحده يمنع فئة كاملة من أخطاء البيانات المكرّرة.
• أعد أخطاء واضحة ومتسقة. استخدم رموز حالة HTTP الصحيحة وجسم خطأ متوقّعًا برمز خطأ ثابت يستطيع التطبيق التفرّع بناءً عليه. أما "حدث خطأ ما" مع حالة 200 فكابوس في التتبّع ويجعل المعالجة الجيدة في جهة العميل مستحيلة.
• اضبط مهلات زمنية وتدهور برشاقة. إن كانت تبعية غير حرجة بطيئة، أعد ما لديك بدل تعليق الطلب بالكامل. فصفحة منتج تُحمَّل بدون قسم التوصيات أفضل من صفحة لا تُحمَّل أبدًا.

استراتيجية الأداء والـ Caching

الـ caching هو نقطة التقاء scalability الخاصة بالـ backend وسرعة الموبايل. والهدف خدمة أكبر عدد ممكن من الطلبات دون لمس قاعدة البيانات.

• استخدم ترويسات HTTP للـ caching. تتيح ETags وCache-Control للعملاء والطبقات الوسيطة تجنّب إعادة تنزيل بيانات لم تتغيّر. فاستجابة 304 Not Modified أرخص بكثير من إعادة بناء الحمولة الكاملة وإرسالها.
• خزّن البيانات كثيرة القراءة نادرة التغيّر. بيانات الكتالوج والإعدادات والقوائم المرجعية مثالية لطبقة caching مثل Redis. ومعظم تطبيقات الموبايل تقرأ أكثر بكثير مما تكتب، لذا فإن caching القراءات يعطي أكبر عائد.
• ادفع بدل أن تسأل باستمرار حيث يهم. التطبيقات التي تستعلم من endpoint باستمرار "تحسّبًا" تولّد حملًا هائلًا مهدورًا. وللاحتياجات اللحظية مثل الدردشة أو تتبّع التوصيل أو الحالة الحيّة، فإن push notifications أو قناة realtime خفيفة تتوسّع أفضل بكثير من آلاف الأجهزة التي تسأل "هل من جديد؟" كل بضع ثوانٍ.

في الأنظمة عالية الإنتاجية مثل منصات POS والتوصيل، تكون قرارات الـ caching والـ push هذه غالبًا الفرق بين خادم واحد متواضع وعنقود مكلف ومُفرط في التجهيز.

تأمين الـ API وإدارة إصداراته

التوسّع بلا أمان عبء، والـ API الذي لا يستطيع التطوّر يتحوّل إلى قفص.

• استخدم رموزًا قصيرة العمر للمصادقة. اعتمد access tokens مع refresh tokens بدل بيانات اعتماد طويلة العمر. فقِصَر مدة الصلاحية يحدّ من الضرر عند تسرّب الرمز، وهو أمر أهم على أجهزة قد تُفقد أو تُخترق.
• حدّد معدل الطلبات لكل عميل. احمِ الـ backend من إصدارات التطبيق المعيبة ومن الحركة المسيئة بوضع سقف لعدد الطلبات التي يجريها عميل واحد ضمن نافذة زمنية. هذا يمنع جهازًا واحدًا سيئ السلوك من إضعاف الخدمة للجميع.
• استخدم versioning من البداية. إصدارات التطبيق القديمة تبقى على هواتف المستخدمين شهورًا بعد إطلاقك للتحديث، ولا يمكنك إجبار الجميع على الترقية. ووضع رقم إصدار في مسار الـ API أو في الترويسة من اليوم الأول يتيح لك تغيير السلوك للعملاء الجدد دون كسر القائمين بالفعل.

أهم النقاط

• صمّم endpoints الـ REST API حول شاشات الموبايل وظروف الشبكة الحقيقية لا حول جداول قاعدة بياناتك.
• قسّم القوائم المتنامية على صفحات، وادعم الحمولات الأصغر، وقلّل رحلات الذهاب والإياب لإبقاء التطبيق سريعًا والـ backend رخيص التوسّع.
• عامل إعادة المحاولة والأعطال كأمر طبيعي: مفاتيح idempotency والأخطاء المتسقة تمنع كوارث البيانات المكرّرة.
• اعتمد على caching الخاص بـ HTTP، وطبقة cache للبيانات كثيرة القراءة، وعلى الـ push بدل الاستعلام المتكرر لخفض حمل الـ backend بشكل كبير.
• استخدم رموزًا قصيرة العمر، وتحديدًا لمعدل الطلبات لكل عميل، وversioning للـ API ليبقى النظام آمنًا وقادرًا على التطوّر بأمان.

بناء backend للموبايل يبقى سريعًا وموثوقًا مع نموّه هو انضباط في التصميم لا تحسين في اللحظة الأخيرة. في SummationWorks نصمّم ونبني REST APIs وbackends موبايل قابلة للتوسّع لتطبيقات عبر الخليج ومصر وخارجها. استكشف خدماتنا، واطّلع على أعمالنا، أو تواصل معنا لنناقش ما يحتاج backend تطبيقك إلى التعامل معه تاليًا.