أنواع الـ API ولماذا تختار REST أو JWT أو GraphQL
الـ API ليست مجرد Endpoints ترجع JSON. هي عقد تقني بين نظامين، وحدود واضحة تفصل بين من يطلب البيانات ومن يملكها. أي خطأ في تصميمها يتضخم مع الوقت، وأي قرار معماري فيها يؤثر على الأداء، الأمان، وقابلية التوسع.
السؤال ليس كيف أكتب API… السؤال الحقيقي: أي نمط أستخدم؟ ولماذا؟
ما هي الـ API فعليًا؟
الـ API هي واجهة تواصل. تسمح لنظام آخر بالتعامل مع تطبيقك دون معرفة تفاصيله الداخلية. هي طبقة تجريد (Abstraction Layer) تحمي المنطق الداخلي وتقدم واجهة مستقرة للاستخدام.
عندما تبني API أنت لا تبني مسارات فقط، أنت تصمم عقد طويل الأمد.
1) REST API
REST هو النمط الأكثر انتشارًا. يعتمد على HTTP بشكل مباشر ويستخدم الأفعال القياسية:
- GET
- POST
- PUT / PATCH
- DELETE
مثال بسيط:
GET /api/users
POST /api/users
GET /api/users/10
DELETE /api/users/10لماذا REST شائع؟
- واضح وبسيط
- يعتمد على بروتوكول HTTP القياسي
- سهل الاختبار
- قابل للتخزين المؤقت (Caching)
متى يكون REST مناسبًا؟
- أنظمة CRUD تقليدية
- Backend لتطبيقات موبايل
- Microservices واضحة الحدود
- أنظمة تحتاج استقرار طويل المدى
مشاكله
- Over-fetching (جلب بيانات أكثر من اللازم)
- Under-fetching (الحاجة لعدة طلبات لجلب بيانات مترابطة)
- إدارة الإصدارات (v1, v2, v3)
REST قوي ومستقر، لكنه ليس حلًا سحريًا لكل الحالات.
2) JWT Authentication
JWT ليست نمط API بحد ذاته، بل طريقة توثيق (Authentication). تعتمد على JSON Web Token لتوثيق المستخدم دون الحاجة لتخزين Session على السيرفر.
يتكوّن التوكن من:
- Header
- Payload
- Signature
مثال Header:
{
"alg": "HS256",
"typ": "JWT"
}متى يكون JWT مناسبًا؟
- تطبيقات SPA
- تطبيقات موبايل
- أنظمة Microservices
- أنظمة تحتاج Stateless Authentication
نقاط يجب الانتباه لها
- لا تخزن بيانات حساسة داخل Payload
- استخدم Expiration دائمًا
- فكر في آلية إبطال التوكن (Revocation)
JWT يوفر أداء أفضل في الأنظمة الموزعة، لكن يحتاج تصميم أمني واعي.
3) GraphQL
GraphQL مختلف عن REST. بدل عدة Endpoints، لديك Endpoint واحد غالبًا:
POST /graphqlالعميل هو من يحدد شكل البيانات المطلوبة.
مثال Query:
{
user(id: 1) {
name
posts {
title
}
}
}لماذا يستخدم GraphQL؟
- تجنب Over-fetching
- مرونة عالية في تحديد البيانات
- مناسب للتطبيقات المعقدة
متى يكون مناسبًا؟
- واجهات Frontend معقدة
- بيانات مترابطة بعمق
- تطبيقات تحتاج تحكم دقيق في الاستجابات
عيوبه
- تعقيد أعلى في الحماية
- صعوبة في الكاش التقليدي
- إمكانية إنشاء Queries ثقيلة تؤثر على الأداء
GraphQL يعطي مرونة كبيرة، لكنه يحتاج رقابة صارمة على مستوى الأداء.
REST vs GraphQL
| المعيار | REST | GraphQL |
|---|---|---|
| عدد المسارات | متعدد | واحد غالبًا |
| التحكم بالبيانات | السيرفر | العميل |
| سهولة التخزين المؤقت | سهل | أكثر تعقيدًا |
| مستوى التعقيد | أبسط | أعلى |
متى تختار كل واحد؟
- بيانات تقليدية وواضحة → REST
- واجهة معقدة تحتاج مرونة عالية → GraphQL
- تطبيق موزع يحتاج Stateless Auth → JWT
لا يوجد خيار أفضل مطلقًا. هناك خيار أنسب حسب طبيعة المشروع.
الخلاصة
المشكلة في أغلب المشاريع ليست في اختيار REST أو GraphQL. المشكلة تكون في:
- تصميم سيء للبيانات
- غياب Versioning
- توثيق غير واضح
- إهمال الأداء منذ البداية
API جيدة تبنى على عقد واضح، تصميم منطقي، أمان محسوب، وأداء مدروس. وأي API تكبر بدون تخطيط… تتحول إلى عبء يصعب إصلاحه لاحقًا.