← الكورسات
الـ REST API هو المعيار الأكثر شيوعاً للتواصل بين الحواسيب عبر الإنترنت. هو مش مواصفة تقنية ولا تكنولوجيا ولا فريمورك، بل هو مجموعة قواعد نسميها "REST Constraints".
إذا التزمنا بهاي القيود، بنضمن أن الـ REST API يكون مرن وسريع وقابل للتوسع (Scalable).
العميل (Client) هو اللي بيطلب البيانات، وهو منفصل تماماً عن الخادم (Server) اللي بيرد بالبيانات المطلوبة.
هالشي مهم لأنه بيسمح لكل طرف يكون مستقل عن الثاني، يعني ممكن نطور الـ Frontend لحاله بدون ما نغير أي شي بالـ Backend، والعكس صحيح.
كل طلب بالـ REST API لازم يكون مستقل تماماً عن أي طلب ثاني. يعني ما لازم يكون في شي اسمه ذاكرة أو Session بالخادم.
كل طلب من العميل لازم يحتوي على كل المعلومات اللازمة للسيرفر ليفهم شو العميل بده. السيرفر ما بيخزن معلومات عن المستخدم، لازم كل طلب يحتوي البيانات الضرورية مثل الـ IDs أو الـ Tokens.
هاد بيخلي الخادم أسرع وقابل للتوسع لأنه ما في داعي يخزن بيانات كل مستخدم.
السيرفر لازم يحدد إذا البيانات ممكن تخزينها مؤقتاً (Cache) عند العميل أو لا. إذا نفس البيانات كانت مطلوبة كثير، ممكن تخزينها وتستخدم لاحقاً مما يقلل الضغط على السيرفر.
الخادم بيحدد مدى صلاحية البيانات عن طريق شي اسمه Cache-Control Header.
كل RESTful API لازم يكون عنده واجهة محددة. ما بهم من عبيحكي مع الخادم، سواء كان متصفح أو موبايل أو تلفزيون.
كلهم لازم يستخدموا نفس القواعد، نفس الـ Endpoints، ونفس الـ Methods.
النظام ممكن يكون مقسم لأكثر من طبقة. العميل مش ضروري يعرف إذا عبيتعامل مع السيرفر الأساسي أو مع سيرفر وسيط كـ Proxy أو Cache Server.
هاد بيعطي أمان وسهولة بالتوزيع، وممكن تضيف Load Balancers لتوزيع الطلبات بدون ما العميل يحس بهالشي.
السيرفر ممكن أحياناً يرجع كود جاهز للتنفيذ (Code on Demand)، ممكن يكون JavaScript. هالشي اختياري ومش من أساسيات الـ REST API.
الموارد بالـ REST API بتنتظم بمجموعة من المعرفات الفريدة اللي هي الـ URIs (Uniform Resource Identifiers). الأهم هو استخدام أسماء وليس أفعال، والأسماء دايماً تكون جمع:
| الغلط | الصح |
|---|---|
/getProducts | /products |
/createUser | /users |
/deleteProduct/1 | /products/1 |
مثلاً، لما الـ Client يبعث طلب لـ /products، السيرفر بيفهم إنو هو عبيطلب كل المنتجات، بروح لقاعدة البيانات، يجيبها، ويرجعها للـ Client.
اشترك في النشرة البريدية
دروس جديدة، مقالات، وأدوات مباشرة لبريدك.
التواصل بين الـ Client والـ Server بصير عن طريق بروتوكول HTTP اللي فيه أربع طرق رئيسية:
| HTTP Method | العملية | المعنى |
|---|---|---|
GET | Read | قراءة بيانات |
POST | Create | إنشاء مورد جديد |
PUT | Update | تحديث مورد موجود |
DELETE | Delete | حذف مورد موجود |
إذا أخدنا أول حرف من كل واحدة طلع معنا مبدأ اسمه CRUD - Create, Read, Update, Delete.
لما بنبعث طلب للسيرفر، الـ Request ممكن تحتوي على Body فيه بيانات كـ Payload. بالعادة بيكون بصياغة JSON:
{
"name": "New Product",
"quantity": 10,
"price": 50.99
}السيرفر بيستلم الطلب، بيعالج المعلومات، وبيرجع الـ Response.
مع كل Response بيرجع شي اسمه HTTP Status Code اللي بيعرفنا شو صار بالطلب:
| النطاق | المعنى | أمثلة |
|---|---|---|
2xx | نجاح | 200 OK, 201 Created |
3xx | إعادة توجيه | 301 Moved Permanently |
4xx | خطأ من الـ Client | 400 Bad Request, 404 Not Found |
5xx | خطأ من الـ Server | 500 Internal Server Error |
مثلاً إذا الـ Client بعث طلب ناقص بيانات، السيرفر برجع 400 Bad Request. وإذا في مشكلة بالسيرفر نفسه، برجع 500 Internal Server Error.
ملاحظة مهمة: لما السيرفر يرجع 500، الـ Client ممكن يحاول يعيد إرسال الطلب، بس لازم يكون حذر. الـ GET والـ DELETE آمنين للتكرار، أما الـ POST فهي بتنشئ مورد جديد في كل مرة، مما ممكن يؤدي لبيانات مكررة.
إذا كان الـ API بيرجع كميات كبيرة من البيانات، من الأفضل استخدام Pagination أو التقسيم إلى صفحات.
أغلب الوقات بتستخدم عن طريق Query String:
GET /products?limit=10&offset=20
هيك بنرجع للـ Client البيانات على شكل صفحات بدل ما نرجع كل شي مرة وحدة.
الـ API Versioning هو إعطاء إصدار للـ API. هالشي مهم لأنه بيحافظ على التوافق مع الإصدارات السابقة.
مثلاً إذا حدّثت الـ API، الأفضل يكون في Endpoints مختلفة:
GET /api/v1/products
GET /api/v2/products
هيك بتعطي وقت للـ Developers اللي عم يستخدموا الـ API تاعتك يتكيفوا مع الإصدار الجديد.
كل هالمفاهيم رح نتطرق عليها بشكل عملي بالفيديو الجاي ونطبق كل المعلومات اللي تعلمناها.