ورقة وقلم وتعالوا نتكلم عن الأساسيات الخمسة لتصميم ال RESTful APIs زي ما الكتاب بيقول
1. Stateless
- كل HTTP Request من ال Client للـ Server مفروض يكون مستقل تمامًا، ويحتوي على جميع المعلومات اللازمة لفهم الـ Request, وبالتالي ال Server مش محتاج يحتفظ بال session بين كل طلب والثاني ودا يفيدنا جدًا في إنه يجعل النظام أبسط وأسهل في التوسع.
مثال:
لو بعت Request إلى /orders/123، لازم الطلب يحتوي على ال Auth Token أو بيانات المصادقة، لأن ال Server لا يحتفظ بمعلومات عن مين هو ال Client.
2. Cacheable
- من المفترض أن تٌصمم الـ API Responses بحيث توضح هل يمكن تخزينها مؤقتًا (Cache) أم لا. ودا بنستخدمه في تقليل الحمل علي ال Server وتحسين ال Response time فكثير من الطلبات قابلة للتخزين المؤقت لأن معدل تغير البيانات مش بالسرعة الكبيرة بين كل طلب والثاني.
مثال:
ال Response من طلبك ل /products ممكن نخزنها في الذاكرة المؤقتة لمدة محددة وبالتالي خلال تصفحي هقلل عدد الطلبات للـ Server عشان أحصل على نفس البيانات.
3. Uniform Interface
- التواصل بين الـ Client و الـ Server يجب أن يتم عبر واجهة واحدة موحدة وبسيطة. يعتبر دا أهم مبادئ تصميم ال RESTful APIs و بنلاحظ دا في أن كلنا بنصمم و بنتعامل مع ال APIs بنفس ال URIs وبنستخدم ال HTTP Methods بنفس الطريقة بغض النظر عن تنظيمنا لل Application أو نوع ال Server, دا بيسهل ويسرع عملية تعلم و صنع ال API وكذلك استخدامها
4. Code-on-Demand
- ممكن ال Server يبعت كود قابل للتنفيذ (مثل JavaScript) يقدر ال Client بتشغيله مؤقتًا مش بس بيانات.ودي تعتبر من المبادئ الاختيارية في التصميم واللي مش بنلجأ ليها كثير كون إرسال وتنفيذ كود علي ال Client تعتبر عملية غير سلسة وقد تكون في بعض الأحيان غير آمنة.
مثال:
عند زيارتك لصفحة منتج يقوم ال Server بإرسال كود Javascript يعرض عد تنازلي لعروض الخصم على المنتج بحسب بيانات المنتج.
5. Layered System
- يمكن للـ API أن يكون خلف طبقات متعددة (مثل خوادم وسيطة، Proxy Gateways،) دون معرفة ال Client بذلك. بكدا الClient بيتواصل فقط مع “الواجهة” وميعرفش اللي بيحصل وراء الكواليس. دا بيتيح لينا ميزات مختلفة زي سهولة التواصل وسهول التوسع عن طريق إضافة طبقات مختلفة مع الاحتفاظ بنفس طريقة التواصل .
[