كود يوضح طريقة بناء متحكم في RESTful API يوفر العمليات السحابية المذكورة في الصورة

الكود متاح باللغات والتقنيات البرمجية :
- ASP.NET CORE WEB with C#
- Node.js with JavaScript
- Laravel with PHP

https://whatsapp.com/channel/0029VbAobzhAInPuPXRCW12m/171

الصورة توضح طرق المصادقة في REST API تعرض أربعة أنواع شائعة من طرق المصادقة.

--------------------------------

كود يوضح طريقة :
- بناء RESTful API تستخدم طرق المصادقة المذكورة في الصورة
- مرفق وصف توضيحي لنقاط قوة ونقاط ضعف كل طريقة قبل الكود

الكود متاح باللغات والتقنيات البرمجية :
* ASP.NET CORE WEB with C#
* Node.js with JavaScript
* Laravel with PHP

# كود كل لغة في ملف مستقل
# يوجد تعليقات توضيحية لكي يفهم المبتدئين

https://claude.ai/share/afb3fb10-367d-4204-a86a-8eeeb24a45ba

قد تحتاج VPN اذا لم تستطع دخول منصة Cluade AI

الصورة توضح طرق المصادقة في REST API تعرض أربعة أنواع شائعة من طرق المصادقة. دعونا نشرح كل نوع بالتفصيل مع أمثلة.

1. Basic Authentication (المصادقة الأساسية):

في هذه الطريقة، يتم إرسال اسم المستخدم وكلمة المرور مع كل طلب من العميل إلى الخادم. هذه الطريقة بسيطة ولكنها غير آمنة لأنها ترسل بيانات الاعتماد (اسم المستخدم وكلمة المرور) في النص العادي، مما يجعلها عرضة للتجسس إذا لم يتم استخدام طبقة تشفير مثل HTTPS.

خطوات العملية:

1. يطلب العميل (Client) الوصول إلى مورد معين.

2. يطلب الخادم (Server) اسم المستخدم وكلمة المرور.

3. يرسل العميل بيانات الاعتماد إلى الخادم.

4. يتم التحقق من صحة بيانات الاعتماد، وإذا كانت صحيحة، يقوم الخادم بإرجاع الموارد المطلوبة.

مثال:

إذا كنت تبني تطبيقًا داخليًا بسيطًا ولا تحتاج إلى حماية صارمة مثل تطبيق يستخدم على الشبكة المحلية فقط، يمكنك استخدام المصادقة الأساسية.

ملاحظة:

لا ينصح باستخدام هذه الطريقة في بيئات الإنتاج دون تشفير، مثل استخدام HTTPS.

---

2. OAuth Authentication (مصادقة OAuth):

OAuth هو بروتوكول مصمم لتفويض الوصول إلى المستخدمين، حيث يسمح لتطبيقات خارجية بالوصول إلى الموارد على حساب المستخدم دون مشاركة كلمة المرور الخاصة بالمستخدم مع التطبيق الخارجي.

خطوات العملية:

1. يقدم العميل طلب تفويض للوصول إلى مورد.

2. المستخدم يوافق على التفويض.

3. يتم إصدار رمز تفويض (Authorization Grant) للعميل.

4. العميل يحصل على رمز الوصول (Access Token) باستخدام رمز التفويض.

5. العميل يرسل رمز الوصول للخادم.

6. إذا كان الرمز صحيحًا، يعيد الخادم البيانات المطلوبة.

مثال:

عند تسجيل الدخول إلى تطبيق مثل Instagram باستخدام حسابك على Google أو Facebook، يتم استخدام OAuth لمشاركة بياناتك مع التطبيق بدون كشف كلمة مرور حسابك الأساسي.

---

3. API Key Authentication (المصادقة باستخدام مفاتيح API):

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

خطوات العملية:

1. يقوم العميل بإنشاء مفتاح API.

2. يتم تخزين المفتاح من قبل العميل.

3. العميل يرسل الطلب إلى الخادم باستخدام مفتاح API.

4. الخادم يتحقق من صحة المفتاح ويعيد الموارد المطلوبة.

مثال:

هذه الطريقة مفيدة للتطبيقات الداخلية أو المشاريع الصغيرة. على سبيل المثال، إذا كنت تبني تطبيقًا للوصول إلى خدمة طقس عامة، يمكنك استخدام مفتاح API لتأمين الوصول إلى البيانات.

---

4. Token Authentication (المصادقة باستخدام الرموز):

في هذه الطريقة، يقوم العميل بتسجيل الدخول أولًا ويستلم رمزًا مميزًا (Token) يتم استخدامه في الطلبات اللاحقة. الرمز يكون عادة مشفرًا ويحتوي على تفاصيل حول المستخدم.

خطوات العملية:

1. يقوم المستخدم بتسجيل الدخول والحصول على رمز مميز.

2. يرسل العميل هذا الرمز في كل طلب للتحقق من هويته.

3. يتم التحقق من الرمز من قبل الخادم.

4. إذا كان الرمز صالحًا، يتم إرجاع البيانات المطلوبة.

مثال:

تستخدم هذه الطريقة غالبًا في تطبيقات الصفحة الواحدة (Single Page Applications) أو تطبيقات الجوال حيث يتم إصدار رمز JWT بعد تسجيل الدخول ويستخدم لتفويض الطلبات المستقبلية.

---

ملاحظات ختامية:

Basic Authentication جيد للتطبيقات الصغيرة ولكن يجب استخدامه مع HTTPS.

OAuth مثالي للتطبيقات التي تحتاج إلى الوصول إلى بيانات المستخدمين من خدمات خارجية مثل Google أو Facebook.

API Key مناسب للمشاريع الصغيرة أو لتأمين واجهات API.

Token Authentication هو الخيار المثالي لتطبيقات الويب أو تطبيقات الجوال التي تحتاج إلى مصادقة مستمرة وسهلة الاستخدام.

كل نوع له ميزاته وعيوبه ويجب اختيار الطريقة المناسبة حسب حاجة التطبيق والمستخدمين.

الصورة تشرح الفرق بين طريقتين شائعتين في التحقق من الهوية والوصول إلى واجهات برمجة التطبيقات (APIs)

الصورة تشرح الفرق بين طريقتين شائعتين في التحقق من الهوية والوصول إلى واجهات برمجة التطبيقات (APIs):

Tokens (مثل JWT) مقابل API Keys

✅ أولاً: مسار التوكن (Token Flow)

يُستخدم غالباً في تطبيقات تسجّل دخول المستخدمين النهائيين.

📌 الخطوات بالتفصيل:

المستخدم يسجّل الدخول عبر تطبيق الويب (مثلاً موقع إلكتروني للتجارة).

التطبيق يُرسل بيانات الدخول (مثل البريد وكلمة المرور) إلى خدمة الهوية (Identity Service).

إذا كانت البيانات صحيحة، تُصدر رمز JWT وترسله للتطبيق.

عند إرسال أي طلب API (مثل "جلب المنتجات")، يتم إرفاق JWT في Header (تحديدًا في حقل Authorization).

الطلب يصل إلى API Gateway، الذي يقوم بإرساله إلى وحدة التحقق من التوكن.

Token Validation يتحقق من:

توقيع التوكن

انتهاء صلاحيته

الصلاحيات أو البيانات داخل التوكن (Claims)

إذا كان التوكن صالح، يُعاد توجيه الطلب إلى الخدمة الداخلية (مثل: خدمة المستخدم أو الطلبات).

تُنفذ الخدمة الطلب، وتتواصل مع قاعدة البيانات لإرجاع النتيجة.

✅ مثال واقعي لمسار التوكن:

موقع تعليمي مثل "Udemy":

عند تسجيل دخولك بحسابك، يُصدر لك JWT.

كل مرة تطلب كورس أو تعديل بياناتك، يتم التحقق من هذا التوكن.

إذا انتهى التوكن أو تم تغييره، يتم رفض الطلب.

🔑 ثانياً: مسار مفتاح API (API Key Flow)

يُستخدم عادةً مع مطوّري الطرف الثالث أو التطبيقات التي تستهلك API مباشرة بدون مستخدم نهائي يسجّل الدخول.

📌 الخطوات بالتفصيل:

مطوّر خارجي يسجّل على بوابة المطوّرين (Developer Portal).

يحصل على API Key فريدة.

يتم تخزين الـ API Key في مخزن مفاتيح آمن (Key Store).

كلما أرسل المطوّر طلبًا إلى API، يضع المفتاح في Header.

الطلب يصل إلى API Gateway، الذي يمرره لخدمة التحقق من المفاتيح.

يتم التحقق من المفتاح باستخدام Key Store.

إذا كان المفتاح صالحًا، يتم تمرير الطلب إلى Public API Service.

تُنفذ الخدمة الطلب وتتواصل مع قاعدة البيانات.

✅ مثال واقعي لمسار API Key:

تطبيق طقس خارجي يستخدم واجهة برمجة التطبيقات من “Weather API”:

يحصل على مفتاح API عند التسجيل.

يستخدمه في كل طلب للحصول على حالة الطقس.

إذا تم إلغاء المفتاح أو تجاوزه الحد، يتم رفض الطلب.

⚖️ مقارنة سريعة:

النقطةJWT TokenAPI Keyيستخدم فيتطبيقات فيها تسجيل دخولتطبيقات عامة أو مطورين خارجيينطريقة التحققالتوقيع، الصلاحيات، الصلاحيةمطابقة المفتاح المخزنأمان أعلى؟✅ نعم، خاصة عند استخدام HTTPS❌ أقل أماناً، لكنه أبسطسهولة الإلغاء؟متوسط (تحتاج Blacklist أو تغيير السر)سهل (إلغاء المفتاح فقط)الاستخدام الأنسبالمستخدمين النهائيينالأنظمة أو الشركاء الخارجيين

✳️ ماذا يمكن إضافته لزيادة الحماية؟

Rate Limiting: الحد من عدد الطلبات للمفتاح أو التوكن.

Scope Restrictions: تحديد الصلاحيات الدقيقة للتوكن أو المفتاح.

IP Whitelisting: حصر استخدام المفتاح من IP محددة.

Expiration & Rotation: توكن مؤقت، ومفاتيح يتم تغييرها دوريًا.

الصورة تشرح الفرق بين REST API و GraphQL من حيث طريقة جلب البيانات من السيرفر إلى العميل (الويب، الموبايل، الكمبيوتر).

الصورة تشرح الفرق بين REST API و GraphQL من حيث طريقة جلب البيانات من السيرفر إلى العميل (الويب، الموبايل، الكمبيوتر). دعني أشرحها بالتفصيل مع أمثلة واقعية وبطريقة مبسطة:

🔷 أولاً: REST API

📌 المثال الموضح:

العميل (مثل تطبيق موبايل) يرسل طلب إلى /user/123 للحصول على بيانات المستخدم.

السيرفر يرد بمعلومات المستخدم: { "name": "Bob", "gender": "male", "order": "456" }

العميل يلاحظ أن هناك معرف طلب (order ID) في الرد، فيرسل طلب جديد إلى /order/456 ليعرف تفاصيل الطلب.

السيرفر يرد بمعلومات الطلب: { "product": "abc", "quantity": "2", "price": "100.00" }

✅ مزايا REST:

بسيط وسهل الفهم.

يدعم الكاش بسهولة.

ممتاز لتطبيقات ذات واجهات مستقرة.

❌ العيوب:

يحتاج عدة طلبات للحصول على معلومات مرتبطة (كما في المثال).

إذا احتجت تغييرات في البيانات المطلوبة، تحتاج تغييرات في الطرفين (العميل والخادم).

🔷 ثانياً: GraphQL

📌 المثال الموضح:

العميل يرسل طلب واحد فقط إلى خادم GraphQL يحتوي على ما يلي:
{ user(id: 123) { name gender order { product quantity price } } }

🎯 النتيجة (الرد):

{ "user": { "id": "123", "name": "Bob", "gender": "male", "order": { "product": "abc", "quantity": "2", "price": "100.00" } } }

ملاحظة: كل البيانات المرتبطة جُمعت في رد واحد فقط!

✅ مزايا GraphQL:

طلب واحد فقط يجلب كل البيانات التي تحتاجها.

العميل يتحكم في ما البيانات التي يريدها، لا أكثر ولا أقل.

ممتاز لتطبيقات ذات واجهات تتغير بسرعة (مثل تطبيقات الجوال الحديثة).

❌ العيوب:

أكثر تعقيداً من REST من حيث التنفيذ.

من الصعب عمل caching بدون أدوات إضافية.

يمكن للمستخدم كتابة استعلامات معقدة قد تستهلك موارد السيرفر (إذا لم تُقيّد جيدًا).

🧪 مثال واقعي:

تخيل أنك تطور تطبيق لمتجر إلكتروني.

باستخدام REST:

لتعرض بيانات المستخدم وطلبه الأخير:

تطلب /users/5

ثم تطلب /orders/987

باستخدام GraphQL:

تطلب مرة واحدة كل شيء:

{ user(id: 5) { name email lastOrder { id total products { name price } } } }

🧠 متى تختار REST ومتى GraphQL؟

الحالة الأنسب مشروع بسيط أو backend ثابتREST مشروع معقد أو متعدد الواجهات (Web + Mobile)GraphQL
- تحتاج كاش قوي وبسيط REST
- تحتاج مرونة في طلب البيانات GraphQL

شرح مُفصَّل — Best Practices in API Design

شرح مُفصَّل — Best Practices in API Design

حلو — الصورة تلخِّص أهم قواعد تصميم واجهات برمجة التطبيقات (APIs). أدناه شرح مُرتَّب ومفصَّل لكل نقطة مع أمثلة عملية وتنبيهات هندسية مهمة.

1 — تسمية واضحة (Use Clear Naming)

استخدم مسارات (URLs) تعبر عن مجموعات الموارد (collections) وليس أفعال:

جيد: GET /api/products — قائمة منتجات

سيء: GET /api/getProducts

اتبع اتفاقية ثابتة: كل المصادر جمع (/products)، عنصر مفرد عبر المعرف (/products/{id}).

خرائط CRUD إلى HTTP methods:

POST /products → إنشاء (Create)

GET /products / GET /products/{id} → قراءة (Read)

PUT /products/{id} أو PATCH /products/{id} → تحديث (Update)

DELETE /products/{id} → حذف (Delete)

استخدم أسماء معبرة في المسارات للموارد المتداخلة عند وجود علاقة واضحة:

GET /carts/{cartId}/items (علاقة ضمنية واضحة)

2 — الإيديومبوتنسي (Idempotency)

ما معنى Idempotent؟: إعادة نفس الطلب مرارًا لا تغيّر نتيجة العملية بعد التنفيذ الأول.

أي ميثود عادةً تكون idempotent: GET, PUT, DELETE, HEAD. بينما POST و PATCH ليست بالضرورة idempotent.

إذا تريد أن تجعل عمليات الإنشاء (مثل المدفوعات) آمنة لإعادة المحاولة: استخدم Idempotency Key.

مثال: العميل يرسل Idempotency-Key: 123e4567 مع POST /payments. الخادم يخزن النتيجة لهذا المفتاح ويعيدها إذا وصل نفس المفتاح لاحقًا.

انتبه لحفظ مفاتيح الـ idempotency مع TTL مناسب (مثلاً يوم/أسبوع) لتفادي استهلاك الذاكرة.

مثال (رؤوس):
POST /payments Authorization: Bearer <token> Idempotency-Key: abc-123 Content-Type: application/json

3 — الترقيم (Pagination)

لماذا؟ لتجنّب إرسال آلاف السجلات دفعة واحدة وتحميل قاعدة البيانات والشبكة.

Offset-based (الطريقة البسيطة)

استعلام: GET /products?limit=20&offset=40

مميزات: سهل التنفيذ، مناسب للصفحات القابلة للانتقال مباشرة (page 1,2,3).

عيوب: غير فعّال مع مجموعات كبيرة أو تغيّرات متكررة (إدخالات/حذف) — قد يفقد المستخدم تزامن النتائج.

Cursor-based (المفضّل للأداء في قواعد بيانات كبيرة)

الفكرة: تعطي العميل مؤشر (cursor) غير شفاف يمثل آخر سجل تم قراءته.

استعلام: GET /products?limit=20&cursor=eyJpZCI6IjEwMCJ9

مميزات: أداء وثبات أفضل عند التغييرات المتواصلة، مناسب للتنقل "التالي" (next).

عيوب: لا يسمح بسهولة بالقفز إلى صفحة رقمية بعينها، لكنه أفضل للموارد الكبيرة.

رد مثال Cursor:
{ "data": [ ... ], "next_cursor": "eyJpZCI6IjEwMCJ9", "has_more": true }

4 — الفرز والتصفية (Sorting & Filtering)

صمم معايير واضحة للاستعلامات عبر Query Parameters:

مثال: GET /products?filter[category]=electronics&min_price=10&sort=-created_at,name

أنماط شائعة: filter[...], q=search, sort=field (- للترتيب تنازلي).

تأكد من:

توثيق الحقول المسموح فلترتها/الفرز عليها.

حماية ضد SQL injection عبر الـ parameterized queries.

وجود فهارس في DB لدعم الفلاتر الثقيلة (على الحقول الشائعة).

5 — المراجع بين الموارد (Cross Resource References)

أفضلية المسارات المتداخلة عندما تكون العلاقة منطقية وواضحة:

جيد: /api/carts/123/items/321 → يوضح أن العنصر 321 تابع للعربة 123.

أقل تفضيلاً: /api/items?cart_id=123&item_id=321 (طويلة وأقل وضوحاً).

للحالات المعقّدة (علاقات كثيرة ـ many-to-many) يمكن استخدام روابط (HATEOAS) أو حقل relationships في الرد لتضمين الروابط:

"links": { "self": "/api/carts/123", "items": "/api/carts/123/items" }

استخدم include أو expand للسماح باسترداد العلاقات في نفس الاستدعاء إن لزم (GET /orders?include=customer,items).

6 — تحديد المعدل (Rate Limiting)

هدفه حماية الخدمة من الـ spikes ومنع إساءة الاستخدام.

سياسات شائعة: per-user, per-api-key, per-IP، أو per-endpoint.

خوارزميات: Token Bucket, Leaky Bucket.

الاستجابة عند تجاوز الحد: HTTP 429 Too Many Requests مع رأس Retry-After.

من الأفضل إرجاع رؤوس توضح الحالة:

X-RateLimit-Limit: 1000

X-RateLimit-Remaining: 250

X-RateLimit-Reset: 1620000000 (timestamp)

Log & monitor لتعديل السياسات حسب الاستخدام الحقيقي.

7 — إصدار الـ API (Versioning)

تغييرات متناقضة (breaking changes) تتطلب إصدار جديد.

أساليب شائعة:

URL versioning: https://api.example.com/v1/users — سهلة للفهم والتخزين المؤقت (caching).

Header/versioning: Accept: application/vnd.example.v1+json أو X-API-Version: 1 — أنيق لكن أقل وضوحًا في أدوات الـ HTTP.

Query param: ?version=1 — أقل مفضلة.

نصيحة: استخدم URL-based للواجهات العامة، واحتفظ بتوثيق واضح لسياسة الترحيل (deprecation period، رسائل تحذير في الردود).

8 — الأمان (Security)

TLS (HTTPS) إلزامي لكل الطلبات.

مصادقة (Authentication): API Keys, Bearer JWT, OAuth2 (authorization code / client credentials).

تفويض (Authorization): تحقق من الصلاحيات (RBAC / ACL / scopes).

احمِ رؤوس حساسة، لا تعرض الحقول السرية في الردود.

التجديد الآمن للتوكنات (refresh tokens) وتدوير المفاتيح (key rotation).

حماية ضد CSRF للبراوزر، وإعداد CORS محدود المنشأ (Origin).

تشفير البيانات الحساسة عند الراحة (at rest) والنقل.

تدقيق وlog للأحداث الأمنية مع التنبيه (alerts).

مثال رأس مصادقة:
Request Header Authorization: Bearer <token>

9 — معايير إضافية مهمة (لم تُذكر بالوعي في الصورة)

الاستجابة بالأخطاء الموحدة (Consistent Error Format):
مثال JSON ثابت:

{ "error": { "code": "invalid_input", "message": "Email is required", "details": { "field": "email" }, "documentation_url": "https://api.example.com/docs/errors#invalid_input" } }

حالات HTTP مناسبة:

200 OK، 201 Created، 204 No Content، 400 Bad Request، 401 Unauthorized، 403 Forbidden، 404 Not Found، 409 Conflict، 429 Too Many Requests، 500 Internal Server Error.

Caching: دعم ETag, If-None-Match, Cache-Control لزيادة الأداء.

مراقبة وقياس (Observability): Metrics, Tracing, Logs, Error rates, SLOs.

توثيق واضح: استخدم OpenAPI/Swagger، مثال طلب/استجابة، نماذج، أكواد خطأ.

اختبارات عقود (Contract Tests): حماية التوافق بين الخدمة والعميل.

حجم الصفحة الافتراضي والحد الأقصى: فرض حدود limit كمحافظة على الأداء.

Content Negotiation: دعم Accept و Content-Type بوضوح إن لزم (JSON، XML).

سياسة إزالة القدامى (Deprecation): رؤوس أو رسائل تُبلغ العملاء قبل إيقاف endpoint.

أمثلة عملية سريعة (curl)

طلب صفحة منتجات مع فلتر وفرز:
curl "https://api.example.com/products?filter[category]=books&min_price=5&sort=-created_at&limit=20" \ -H "Authorization: Bearer <token>"
إنشاء مورد مع Idempotency Key:
curl -X POST "https://api.example.com/payments" \ -H "Authorization: Bearer <token>" \ -H "Idempotency-Key: order-12345" \ -H "Content-Type: application/json" \ -d '{"amount":100, "currency":"USD"}'

خلاصة سريعة ونصيحة عملية

ابدأ بمواصفات واضحة (OpenAPI)، سمِّ endpoints بعناية، طبّق idempotency حيث يلزم، وفرّ Pagination مناسبًا، وثّق طرق الفرز والتصفية، ضبط Rate Limiting، وفكّر جيدًا في استراتيجية Versioning، ولا تغفل عن الأمان والـ observability.

هذه الممارسات تجعل API قابلًا للتوسّع، سهل الاستخدام للمطوّرين، وأكثر أمانًا واستقرارًا للإنتاج.

الفرق بين JWT و PASETO

أولاً: JWT (JSON Web Token)

JWT هو معيار مفتوح لنقل المعلومات بين طرفين (Client ↔ Server) بشكل آمن نسبيًا.
الـ JWT يتكون من ثلاثة أجزاء:

Header: يحدد نوع التوكن وطريقة التشفير (مثل HS256).

Payload: يحتوي البيانات (Claims) مثل: userId, email, exp.

Signature: توقيع للتحقق أن التوكن لم يتم التلاعب به.

كيف يشتغل؟

المستخدم يسجل دخول بإسم المستخدم وكلمة المرور.

السيرفر يتأكد من صحة البيانات ويولد JWT موقّع.

التوكن يُرسل للعميل ويُخزن عادة في LocalStorage أو Cookies.

عند كل طلب جديد، العميل يرسل JWT في الـ Authorization Header.

السيرفر يتحقق من التوقيع ويقرر قبول أو رفض الطلب.

ميزة JWT: إنه "stateless" يعني السيرفر ما يحتاج يخزن جلسة لكل مستخدم.
مثال واقعي:

في تطبيقات مثل Netflix أو Spotify، بعد ما تسجل دخول، التوكن يحملك معك في كل طلب (تشغيل فيلم/أغنية).

ثانياً: PASETO (Platform-Agnostic Security Tokens)

PASETO هو بديل حديث لـ JWT، صمم لحل مشاكله. فكرته الأساسية: فرض استخدام خوارزميات آمنة بشكل افتراضي.
مكوناته الرئيسية:

Version (V1 أو V2).

Purpose (Public أو Local).

Payload (مشفر أو نص عادي).

أنواع PASETO:

Public PASETO: موقع (Signed) بمفتاح خاص/عام → يضمن سلامة البيانات لكن ليس سريتها.

Local PASETO: مشفر (Encrypted) بمفتاح سري → يضمن سرية البيانات.

كيف يشتغل؟

المستخدم يرسل بياناته.

السيرفر يولد PASETO بالتشفير المناسب.

العميل يرسل التوكن عند الطلبات.

السيرفر يفتح التوكن ويتحقق منه باستخدام المفتاح الصحيح.

ميزة PASETO: ما يسمح باستخدام خوارزميات ضعيفة مثل HS256، بل يفرض خوارزميات حديثة (ChaCha20-Poly1305, Ed25519).
مثال واقعي:

في تطبيقات البنوك أو أنظمة الدفع مثل PayPal أو Stripe، حيث أمان البيانات أهم من كل شيء، PASETO يوفر تشفير افتراضي أقوى.

الميزات والعيوب

ميزات JWT:

سهل الاستخدام ومدعوم في كل اللغات والأطر (Node.js, ASP.NET, Django...).

مناسب للتطبيقات الكبيرة (API, Microservices).

واسع الانتشار وموثق بشكل ضخم.

عيوب JWT:

يسمح باستخدام خوارزميات غير آمنة (مثل none, HS256 إذا أسيء استخدامها).

لا يشفر البيانات، فقط يوقعها → أي شخص معه التوكن يقدر يقرأ الـ Payload.

إذا تسرب التوكن، ما تقدر تبطله إلا بتغيير الـ secret أو عمل Blacklist.

ميزات PASETO:

أمان أفضل بخيارات افتراضية قوية (secure by default).

يدعم التوقيع والتشفير معًا (Integrity + Confidentiality).

يقلل من الأخطاء الأمنية الناتجة عن سوء اختيار الخوارزميات.

عيوب PASETO:

جديد نسبيًا → أقل انتشارًا وأدواته أقل من JWT.

بعض المكتبات والأنظمة لا تدعمه بشكل مباشر.

التعلم عليه أصعب شوية للمطورين الجدد.

تشبيه واقعي مبسط

JWT زي مفتاح إلكتروني لباب الفندق: يفتح لك الباب لكن أي شخص يشوف المفتاح يعرف رقم غرفتك وتاريخ صلاحيتك.

PASETO زي مفتاح مشفر: حتى لو أحد سرقه، ما يعرف التفاصيل لأنه التوكن نفسه مشفر ومبني بخوارزميات أقوى.

مشهد بروتوكولات الـAPI اليوم — شرح عملي ومفصّل

مشهد بروتوكولات الـAPI اليوم — شرح عملي ومفصّل

هناك ستة بروتوكولات/أنماط هي الأكثر حضورًا عند بناء تكاملات وخدمات حديثة: REST، Webhooks، GraphQL، SOAP، WebSocket، gRPC. تحتها تظهر تقنيات مكملة مثل SSE، MQTT، AMQP وأنماط معمارية مثل EDA، ومعايير تبادل أعمال قديمة مثل EDI. فيما يلي شرح مركز مع متى تستخدم كل خيار ولماذا.

1) REST

ما هو؟ أسلوب معماري فوق HTTP (GET/POST/PUT/DELETE…) للتعامل مع “موارد” لها عناوين URL وتمثيلات JSON.
يناسب عندما:

CRUD على بيانات واضحة الكيانات: Users, Orders, Invoices…

واجهات عامة/شركاء يسهل عليهم الاستهلاك.

الحاجة للتخزين المؤقت (caching) وسياسات HTTP القياسية.

المزايا: بسيط، واسع التبني، أدوات غنية (OpenAPI/Swagger)، يسهل نسخه عبر المتصفّح وPostman.
التحديات: تجميع بيانات متعددة في طلب واحد قد يتطلب عدة مكالمات؛ التحميل الزائد/الناقص (over/under-fetch).
ملاحظات تصميم مهمة: ترقيم الإصدارات، معرّفات ثابتة، Idempotency-Key للعمليات الحسّاسة (مثل الدفع)، واستخدام ETag وCache-Control.

2) Webhooks

ما هو؟ نداء عكسي ترسله خدمتُك إلى URL يملكه الطرف الآخر عند وقوع حدث (payment.succeeded مثلًا).
يناسب عندما:

إعلام الأنظمة الشريكة بالأحداث فورًا بدون polling.

تكاملات ماركت بليس/بوابات دفع/مستودعات.

المزايا: آني، يقلّل الاستعلامات المتكررة.
التحديات: الاعتمادية (إعادة المحاولة مع backoff)، الأمن (توقيع HMAC وسرّ مشترك)، ترتيب الرسائل.
أفضل الممارسات:

توقيع كل رسالة وإرفاق timestamp لمنع إعادة التشغيل.

Retry-After + DLQ عند الفشل.

صفحة لإدارة الاشتراكات وHealth checks.

3) GraphQL

ما هو؟ طبقة استعلام تتيح للعميل طلب “بالضبط” الحقول التي يريدها عبر مخطط (Schema) موحّد.
يناسب عندما:

واجهات غنية (ويب/موبايل) تحتاج جمع بيانات من خدمات متعددة بكفاءة.

تقليل عدد الطلبات وتكييف الاستجابة بحسب شاشة العميل.

المزايا: تحكم دقيق في البيانات، نوعية قوية (strongly-typed schema)، introspection، توحيد بوابة بيانات.
التحديات: الحماية من الاستعلامات المكلفة (كسارة/عمق/تعقيد)، التخزين المؤقت أصعب من REST، أدوات رصد خاصة.
ملاحظات: استخدم حدودًا (limits) وquery cost، وPersisted Queries، وDataLoader لتجميع الاستدعاءات.

4) SOAP

ما هو؟ بروتوكول XML صارم مع WSDL وعمليات محددة، شائع في الأنظمة المؤسسية القديمة والجهات الحكومية.
يناسب عندما:

التكامل مع أنظمة قديمة/جهات رسمية لا تدعم إلا SOAP.

احتياج لميزات معيارية مثل WS-Security وTransactions.

المزايا: مواصفات أمنية وتعاملات قوية تاريخيًا.
التحديات: ثقل XML، صعوبة على فرق حديثة، بطء التطوير مقارنةً بـ REST/JSON.

5) WebSocket

ما هو؟ قناة ثنائية الاتجاه طويلة العمر فوق TCP (تبدأ عبر Handshake HTTP)، مناسبة للتحديث الفوري.
يناسب عندما:

محادثة فورية، لوحات حيّة، تعقّب مواقع، ألعاب.

الحاجة لبث من الخادم للعميل والعكس دون فتح طلبات متكررة.

المزايا: زمن كمون منخفض، ثنائية الاتجاه حقيقية.
التحديات: التوسّع والأمان (جلسات طويلة)، التوافق مع شبكات/Proxies، السقوط والعودة (reconnect) مع استئناف الحالة.
بدائل أخف: SSE عندما تحتاج بثًا من الخادم للعميل فقط.

6) gRPC

ما هو؟ إطار RPC عالي الأداء يعتمد HTTP/2 وProtocol Buffers للتسلسل (binary).
يناسب عندما:

اتصالات خدمة-إلى-خدمة (microservices) داخل الشبكة.

حاجات أداء عالية وبث ثنائي الاتجاه، وتعريف واجهات بنوعية صارمة.

المزايا: سريع جدًا، مخططات مُولِّدة للشيفرة، Streams، ضغط فعّال.
التحديات: أقل ملاءمة للمتصفح مباشرة (يُستخدم gRPC-Web)، أدوات تصحيح أقل بساطة من REST.
ملاحظات: أبقه داخليًا، وقدّم بوابة REST/GraphQL خارجية للاستهلاك العام.

تقنيات مُكمِّلة مذكورة في الرسم

SSE (Server-Sent Events): بث أحادي الاتجاه من الخادم للمتصفح عبر HTTP عادي؛ ممتاز للتحديثات الحيّة البسيطة والتنبيهات ولوحات الرصد عندما لا تحتاج قنوات ثنائية الاتجاه كاملة مثل WebSocket.

MQTT: بروتوكول Pub/Sub خفيف للشبكات غير المستقرة وIoT.

AMQP (مثل RabbitMQ): معيار رسائل للمؤسسات (صفوف، تبادل، توجيه) لتكامل غير متزامن وإزالة الازدحام عن الـAPI.

EDA (Event-Driven Architecture): نمط معماري يبني النظام حول أحداث ونواقل رسائل؛ غالبًا يستخدم AMQP/Kafka وWebhooks.

EDI: معايير قديمة لتبادل مستندات الأعمال (فواتير، أوامر شراء) بين مؤسسات؛ ما يزال موجودًا في سلاسل الإمداد.

كيف تختار؟ (دليل قرار سريع)

CRUD قياسي وواجهة للعامة → REST.

تجميع بيانات من خدمات متعددة وتقليل عدد الطلبات لواجهات غنية → GraphQL.

تنبيه الأطراف الخارجية عند وقوع حدث → Webhooks (+ توقيع HMAC وإعادة المحاولة).

بث فوري أحادي الاتجاه للمتصفح (تنبيهات/لوحات) → SSE، وإن احتجت محادثة/تفاعل ثنائي الاتجاه → WebSocket.

تواصل داخلي عالي الأداء بين الميكروسيرفس → gRPC.

تكاملات حكومية/قديمة تُلزِم XML/WSDL → SOAP.

أنظمة IoT أو شبكات ضعيفة → MQTT.

مهام غير متزامنة مرتّبة وضمان التسليم → AMQP مع طوابير ورسائل معاد محاولة.

اعتبارات أمان وأداء مشتركة

المصادقة والتفويض: OAuth2/OIDC للواجهات العامة، مفاتيح خدمة + mTLS بين الخدمات، وتوقيع Webhooks.

الاعتمادية: Idempotency في العمليات الحساسة، سياسات Retry مع Backoff، ورسائل “مرة واحدة على الأكثر/الأقل”.

الرصد: تتبّع موزّع (Trace/Span IDs)، قياسات Latency/Throughput/Error Rate، وسجلات غنية.

التوافق والتخزين المؤقت: REST يستفيد من Cache طبقة HTTP؛ GraphQL يحتاج إستراتيجيات خاصة؛ gRPC يعتمد عادةً على Cache طبقة التطبيق.

الإصدارات: حافظ على توافق خلفي؛ استخدم Versioning للـREST وSemVer لملفات proto وGraphQL deprecations.

توصية تطبيقية لنظام مثل Genius Link (محاسبي متعدد المستأجرين)

واجهة عامة للمطورين والعملاء: REST موثّق بـ OpenAPI.

لوحات داخلية غنيّة/تجميع بيانات متعددة: GraphQL Gateway داخلي للواجهات.

تنبيهات فورية (سند قُبِض/فاتورة دفعت): Webhooks للشركاء + SSE/WebSocket لتطبيقات الويب.

تكاملات حكومية/بنكية قديمة: SOAP/EDI عند الاضطرار.

بين الخدمات (حسابات/مدفوعات/تحليلات): gRPC داخل الشبكة + AMQP لطوابير المهام.

موبايل وشبكات ضعيفة: فكّر في مزج REST مع تخزين محلي ومزامنة، وMQTT إذا ظهرت سيناريوهات اتصال متقطع.

التحكّم في الوصول يحدّد من يدخل ومن يُمنع — لكن القواعد تختلف:

التحكّم المستند للأدوار (RBAC): الوصول مبني على أدوار (مثل: Maintainer, Viewer). بسيط وقابل للتوسّع.

التحكّم المستند للسمات (ABAC): الوصول مبني على سمات/خصائص (مستخدم، مورد، بيئة). مرن جدًا، لكنه أعقد.

قوائم التحكم بالوصول (ACL): أذونات صريحة لكل مستخدم أو مجموعة. مباشر، لكن يصعب إدارته على نطاق واسع.


RBAC = أدوار.
ABAC = سمات.
ACL = أذونات صريحة.

سؤال للتفكير: هل اضطررت يومًا للانتقال من نموذج لآخر؟ ما الذي دفعك للتغيير؟

لبنات بناء الشبكات الحديثة
كل شبكة حديثة — من واي-فاي المنزل إلى بنية السحابة العالمية — تُبنى على عدد قليل من المكوّنات الأساسية. إليك لمحة سريعة عنها:

الشبكات الأساسية (Core Networking):
المحوّل (Switch) يَصل الأجهزة داخل نفس الشبكة المحلية. كل مكتب يضم العشرات منه.
الموجّه (Router) يُمرّر الحزم بين الشبكات المختلفة. هو بوابتك للإنترنت وما بعده.
SD-WAN هي طريقة الشركات الحديثة لربط الفروع. معرفة بالبرمجيات، مرنة، وأقل تكلفة بكثير.