Featured blog image
250 كلمة 2 دقيقة للقراءة

REST API و GraphQL الفرق الحقيقي بينهما ومتى تستخدم كل تقنية؟

فيه مطورين أول ما يتعلموا يعملوا API يحفظوا: GET - POST - PUT - DELETE وبعدها يقولك: "أنا كده بعمل RESTful API"

لكن الحقيقة؟ مش كل API فيها GET و POST تبقى RESTful. ومش كل Endpoint شغال يبقى معمول صح.

وأول ما تسمع GraphQL ممكن تحس إنه مجرد:

REST لكن بطريقة مختلفة شوية.

وده مش صحيح. GraphQL مختلف من الأساس في طريقة التفكير. وقبل المقارنة لازم نفهم يعني إيه REST أصلاً.

ما هو RESTful API؟

REST اختصار لـ:

Representational State Transfer

الفكرة إنك تتعامل مع النظام كـ Resources بدل أوامر مباشرة.

بدل:


/getUser
/createOrder
/deleteProduct

تفكر بالشكل ده:


/users
/orders
/products

ثم تستخدم HTTP Methods: 


GET /users/5
POST /users
PUT /users/5
PATCH /users/5
DELETE /users/5
  • GET: جلب بيانات
  • POST: إنشاء بيانات
  • PUT: تعديل كامل
  • PATCH: تعديل جزئي
  • DELETE: حذف

الفكرة المهمة:

  • الـ URL يمثل Resource
  • الـ Method يمثل العملية

أخطاء شائعة في تصميم REST APIs

كتير تشوف حاجات زي:


POST /getAllProducts
POST /deleteUser
GET /createOrder

وده مش RESTful حتى لو شغال.

فكرة Stateless في REST

REST مبني على مفهوم مهم:

Statelessness

كل Request لازم يحمل المعلومات الخاصة بيه. السيرفر ميفترضش إنه فاكر طلب قديم.

زي:

  • Authorization Token
  • Headers
  • Cookies

وده بيساعد في:

  • Scaling
  • Load Balancing
  • Caching
  • Debugging

قوة REST الحقيقية

REST بيستفيد من HTTP بالكامل: 


200 OK
201 Created
204 No Content

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found

500 Internal Server Error
وكمان:
  • Headers
  • ETags
  • Cache-Control
  • CDN Caching

مشكلة REST: كثرة Requests

تخيل شاشة Profile محتاجة:

  • بيانات المستخدم
  • الطلبات
  • المنتجات
  • السلة

ممكن تعمل: 


GET /users/5
GET /users/5/orders
GET /orders/101/items
GET /orders/102/items
GET /cart/summary

يعني شاشة واحدة فقط تعمل 5 أو 6 Requests.

وده بيظهر أكثر في:

  • Mobile Apps
  • Slow Networks

هنا ظهر GraphQL

GraphQL خلى الـ Client يحدد البيانات المطلوبة بنفسه.

مثال:


query {
  user(id: 5) {
    name

    orders {
      total

      items {
        productName
        price
      }
    }

    cart {
      itemsCount
    }
  }
}

الرد هيكون بالبيانات المطلوبة فقط.

لا زيادة… ولا نقصان.

مشاكل REST التي يحلها GraphQL

1- Over-fetching

Endpoint ترجع بيانات أكتر من المطلوب.

مثلاً:


{
  "name": "Belal",
  "phone": "...",
  "address": "...",
  "birthDate": "..."
}

مع إن الشاشة محتاجة الاسم فقط.

2- Under-fetching

Endpoint واحدة لا تكفي، فتحتاج Requests إضافية.

هل GraphQL أسرع من REST؟

الإجابة: مش دائمًا.

GraphQL بيضيف:

  • Parsing
  • Validation
  • Resolvers
  • Authorization
  • Complexity Analysis

وده معناه Overhead إضافي.

في الأنظمة البسيطة: REST أحيانًا أسرع.

ما هي Resolvers في GraphQL؟

في REST: كل Endpoint لها Controller.

في GraphQL: كل Field تقريبًا له Resolver. 


User Resolver
↓
Orders Resolver
↓
Items Resolver

مشكلة N+1 Problem في GraphQL

لو عندك: 100 User

والكل عنده Orders.

ممكن يحصل: 


SELECT * FROM users;

SELECT * FROM orders WHERE user_id = 1;
SELECT * FROM orders WHERE user_id = 2;
SELECT * FROM orders WHERE user_id = 3;

...

يعني 101 Query بدل واحدة أو اتنين.

عشان كده المشاريع الكبيرة تستخدم:

DataLoader Pattern

ليه Caching أسهل في REST؟

REST: 

GET /products/5
سهل يتخزن في:
  • Browser Cache
  • CDN
  • Reverse Proxy
أما GraphQL غالبًا: 

POST /graphql
فالـ Caching أعقد.

إمتى تستخدم REST؟

  • CRUD Systems
  • Authentication
  • Public APIs
  • Uploads
  • Webhooks
  • Cache-heavy APIs

إمتى تستخدم GraphQL؟

  • Dashboards
  • React Apps
  • Mobile Apps
  • Complex Data
  • Dynamic UI

هل لازم تختار واحد فقط؟

لا. شركات كتير تستخدم الاثنين:

REST

  • Login
  • Uploads
  • Payments
  • Webhooks

GraphQL

  • Dashboards
  • Aggregated Data
  • Complex Screens

وده اسمه: Hybrid Architecture

الخلاصة

GraphQL مش REST الجديد. وREST مش تقنية قديمة.

كل واحد معمول لحل مشاكل مختلفة.

المهندس الشاطر مش اللي يتبع الترند، لكن اللي يعرف:

إمتى يستخدم كل تقنية… وليه.
شارك الآن ؟

احدث الأخبار

مقالات مميزة

تواصل معي