ما هي REST API؟ فهم الفكرة بالمثال خطوة بخطوة

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

المشكلة اللي REST API بتحلّها

تخيّل إن عندك تطبيق موبايل، و Dashboard على الويب، ونظام داخلي جوه الشركة، وكلهم محتاجين يتعاملوا مع نفس الداتا: Users, Orders, Products.

لو كل واجهة من دول بتتعامل مع قاعدة البيانات بطريقتها الخاصة، ومع كل تعديل في الـ Database أو في اللوجيك لازم تفتح ٣ أو ٤ مشاريع وتعدّل فيهم، ده كابوس صيانة حقيقي خصوصًا لما المشروع يكبر.

الحل إن يكون فيه طبقة موحّدة في النص: باب رسمي أي عميل (Web, Mobile, Service تاني) يمرّ منه عشان يطلب أو يعدّل الداتا، من غير ما يهمّه تفاصيل الـ Database أو لغة الباك إند. هنا بييجي دور API، ولما نمشي حسب أسلوب REST في تصميمه بنسميه REST API.

يعني إيه REST API بالظبط؟

تعريف بسيط

REST اختصار لـ Representational State Transfer، وده اسم شكله معقّد شوية لأسلوب (Architectural Style) لتصميم الـ APIs، مش تكنولوجيا مستقلة ولا Framework جاهز.

لما نقول REST API فإحنا نقصد: واجهة برمجية (API) بتسمح لعميل (Client) إنه يتعامل مع Resources على السيرفر (Server) عن طريق بروتوكول HTTP، باستخدام شوية قواعد موحّدة وبسيطة، وغالبًا البيانات بتتبادل في شكل JSON.

بالعربي: طريقة منظمة إن أي تطبيق يطلب ويعدّل الداتا من سيرفر باستخدام HTTP Requests زي GET وPOST وPUT وDELETE، والسيرفر يرد غالبًا بـ JSON منظم.

مثال يوضح الفكرة

لو عندك System لإدارة مقالات (Blog)، هتعتبر إن عندك Resource اسمه posts. من منظور REST API، ممكن يبقى عندك Endpoints بالشكل ده:

• GET /api/posts → رجّعلي كل المقالات.
• GET /api/posts/10 → رجّعلي المقال رقم 10.
• POST /api/posts → أنشئ مقال جديد.
• PUT /api/posts/10 → عدّل المقال رقم 10 (تعديل كامل).
• DELETE /api/posts/10 → امسح المقال رقم 10.

كل ده بيتم فوق HTTP، وبنفس الأفكار اللي أصلاً موجودة في الويب من زمان، وإنت بس بتستخدمها بطريقة منظمة مع الـ API.

REST مبني على Resources و HTTP

Resources بدل Functions

واحدة من أهم أفكار REST إنك تفكر في الداتا كـ Resources (مستخدم، منتج، طلب، فاتورة) مش كـ Functions (getUsers, saveUser).

كل Resource ليه:

• اسم: users, posts, orders…
• عنوان (URI) يوصلّك له: زي /api/users/5.
• تمثيل (Representation) للبيانات، غالبًا في شكل JSON.

بدل ما تعمل Endpoint اسمه /api/getAllUsers، REST يفضّل /api/users مع استخدام HTTP Method مناسب.

HTTP Methods = أفعال موحّدة

REST بيستغل الأفعال اللي HTTP أصلاً بيوفرها، وبيطابقها مع عمليات CRUD المشهورة:

• GET → قراءة بيانات (Read).
• POST → إنشاء بيانات جديدة (Create).
• PUT / PATCH → تعديل بيانات موجودة (Update).
• DELETE → حذف بيانات (Delete).

الفكرة إن أي حد فاهم HTTP يقدر يتوقّع إزاي يتعامل مع الـ API بتاعك تقريبًا من غير ما يقضي وقت طويل في قراءة Documentation معقّدة.

REST كـ Architectural Style (مش أي API فوق HTTP)

مش أي API بيشتغل فوق HTTP يتقال عليه REST. عشان API يكون RESTful، لازم يلتزم بمجموعة قيود (Constraints) أساسية في التصميم.

• Client–Server: فصل واضح بين العميل (اللي يطلب) والسيرفر (اللي ينفّذ ويخزن الداتا).
• Stateless: كل Request مستقل، السيرفر مش بيحتفظ بحالة العميل بين الريكوستات.
• Cacheable: الـ Responses ينفع تتخزّن في كاش لتحسين الأداء.
• Uniform Interface: طريقة موحدة للتعامل مع Resources في كل حتة في الـ API.
• Layered System: تقدر تحط Layers في النص (Gateways, Proxies) من غير ما الكلاينت يحس.
• Code on Demand (اختياري): السيرفر يبعث كود يتنفّذ عند العميل في حالات خاصة.

الالتزام بالمبادئ دي بيخلي الـ API أسهل في الفهم، أسهل في التوسع، وأسهل في الصيانة على المدى البعيد.

لمحة سريعة: REST vs SOAP

• REST: خفيف، بيستخدم HTTP بشكل مباشر، غالبًا JSON، مرن وبسيط في الاستهلاك.
• SOAP: أقدم وأثقل، بيعتمد على XML ورسائل فورمالية، ومناسب أكتر للأنظمة الضخمة (Enterprise).

في أغلب تطبيقات الويب والموبايل الحديثة، REST بيكون الاختيار الطبيعي لأنه أبسط وأخف وأسهل في الدمج مع أي تكنولوجيا تانية.

لو حابب تقرأ تعريفات تقنية أعمق، تقدر ترجع مثلًا إلى: RESTful API Tutorial.

REST APIs في حياتك اليومية

غالبًا أنت بتتعامل مع REST APIs كل يوم من غير ما تحس:

• تطبيق الطقس بيجيب بياناته من REST API خاصة بخدمة الطقس.
• تطبيق البنك على الموبايل بيتكلم مع Backend عن طريق REST APIs عشان يعرض الرصيد والتحويلات.
• متجر إلكتروني (E‑Commerce) بيقدّم REST API لتطبيق الموبايل وDashboard الإدارة في نفس الوقت.

المشترك بينهم إن فيه Backend واحد مدي REST API، وعدة عملاء (Web, Mobile, Services) بيتعاملوا معاه بنفس اللغة: HTTP + JSON.

شكل Request وResponse بسيط في REST API

تعال نأخذ مثال سريع لطلب إنشاء مقال جديد عبر REST API:

POST /api/posts HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "title": "أول مقال عن REST API",
  "body": "المحتوى التجريبي للمقال...",
  "tags": ["rest", "api", "backend"]
}

ورد السيرفر ممكن يكون بالشكل ده:

{
  "data": {
    "id": 10,
    "title": "أول مقال عن REST API",
    "body": "المحتوى التجريبي للمقال...",
    "tags": ["rest", "api", "backend"],
    "created_at": "2026-03-22T10:00:00Z"
  },
  "message": "Post created successfully"
}

اللي يهمّنا هنا إن:

• العميل بعت JSON واضح.
• السيرفر ردّ بـ JSON منظم.
• التفاصيل الداخلية زي نوع قاعدة البيانات أو لغة السيرفر مش ظاهرة للكلاينت.

من منظور مطوّر Laravel / PHP

كمطوّر Laravel أو PHP، فكرة REST API هتشوفها في حاجات زي:

• استخدام routes/api.php بدل routes/web.php لبناء Endpoints بترجع JSON.
• تعريف Resources زي User وPost وOrder في شكل Models + Controllers.
• استخدام Route::apiResource() عشان تولّد مجموعة Routes RESTful جاهزة (index, show, store, update, destroy).
• التعامل مع Requests وResponses كـ JSON بشكل افتراضي في الـ API.

إحنا في المقال ده ركّزنا على الفكرة نفسها، في المقالات الجاية هننقل الكلام ده لبيئة حقيقية باستخدام Laravel و MySQL خطوة بخطوة.

تمهيد للمقال القادم

لو الصورة لسه مش ثابتة بنسبة ١٠٠٪، ده طبيعي، المقال ده كان مجرد "الصورة الكبيرة" قبل ما ننزل في التفاصيل.

المقال الجاي هيكون عن: أساسيات REST API: Resources, Endpoints, Methods, Status Codes.

في المقال ده هنتعمّق أكتر في:

• إزاي تسمي الـ Resources صح.
• إزاي تختار شكل الـ Endpoints.
• إمتى تستخدم GET أو POST أو PUT أو DELETE عمليًا.
• إزاي تختار HTTP Status Code المناسب لكل حالة.

لو مش فاهم التسمية الصح للـ Resources والـ Endpoints، هتتعب جدًا قدّام لما تيجي توسّع الـ API أو تشتغل في فريق، فالمقال الجاي مهم جدًا.