REST API vs GraphQL: أيهم تستخدم بمشروعك؟

كل مطور backend لازم يسمع هالنقاش بمرحلة ما: REST API وGraphQL، شو الفرق الحقيقي، ومتى تختار كل وحدة؟ هاد شرح عملي بعيد عن التعقيد النظري.

REST — نقاط نهاية متعددة

REST (Representational State Transfer) بيبني الـ API حول موارد (Resources)، كل مورد له نقطة نهاية (endpoint) خاصة فيه:

GET  /api/users/5           → بيانات المستخدم رقم 5
GET  /api/users/5/posts     → منشورات المستخدم رقم 5
GET  /api/posts/12/comments → تعليقات المنشور رقم 12

كل endpoint بيرجع شكل بيانات ثابت محدد مسبقًا من السيرفر. لو العميل (موبايل مثلًا) محتاج بس اسم المستخدم، لسا رح ياخد الكائن كامل (over-fetching).

GraphQL — نقطة نهاية واحدة، طلب محدد

GraphQL بيشتغل بفلسفة مختلفة: نقطة نهاية واحدة فقط، والعميل بيكتب بالضبط شو البيانات يلي بدو ياها بكل طلب:

query {
  user(id: 5) {
    name
    posts {
      title
    }
  }
}

النتيجة: بيانات المستخدم (الاسم فقط) وعناوين منشوراته فقط — مو أي حقل زائد، وبطلب واحد بس (مو 3 طلبات منفصلة زي REST بالمثال أعلاه).

جدول المقارنة

مثال حقيقي: ليش GraphQL بيلمع أحيانًا

تخيّل تطبيق فيه شاشة "بروفايل مستخدم" لازم تعرض: اسمه، صورته، آخر 3 منشورات، وعدد متابعينه. بـ REST التقليدي هذا غالبًا 4 طلبات منفصلة لـ 4 endpoints مختلفة. بـ GraphQL، طلب واحد بس يحدد بالضبط هاي الحقول الأربعة من مصادرها المختلفة.

بالمقابل، لو الـ API بسيط (CRUD عادي بلا شاشات معقّدة مترابطة)، REST أسرع تطويرًا وأسهل صيانة — GraphQL بيضيف تعقيد مو مبرر.

الخلاصة

REST لسا الخيار الافتراضي الصح لمعظم المشاريع لبساطته ونضجه. GraphQL أداة قوية لمشاكل محددة: شاشات معقّدة، واجهات متعددة بحاجات بيانات مختلفة، أو فرق كبيرة بتحتاج مرونة بطلب البيانات. اتعلّم REST أول لأنه الأساس، وGraphQL لما تواجه فعليًا المشكلة يلي بيحلها.

ابدأ مسار REST API الكامل بالعربي — يتضمّن مقدمة عملية بـ GraphQL كمان.