لما المستخدم يفتح رابط منتج التطبيق محتاج يعرف أنهي جزء من الكود مسؤول عن الطلب ده ال Routing هو الربط بين تفاصيل الطلب والمعالج المناسب مش شرط يكون ملف HTML موجود بنفس اسم الرابط

من الطلب لحد الاستجابة

ال Route هو تعريف لمسار وطريقة طلب وال Router هو الجزء اللي بيختار التعريف المناسب وال Handler هو الكود اللي بيتنفذ بعد المطابقة الاستجابة ممكن تكون صفحة HTML أو بيانات JSON أو تحويل لرابط تاني

GET /products/notebook
        -> Router
        -> Product Handler
        -> HTML or JSON Response

طريقة الطلب جزء من المعنى

نفس المسار ممكن يكون ليه سلوك مختلف حسب HTTP Method ال GET لطلب تمثيل للمورد وال POST غالبا لإرسال بيانات للمعالجة وفيه PUT و PATCH و DELETE لاستخدامات تانية حسب تصميم التطبيق

متعملش رابط GET يحذف بيانات لأن زيارة الرابط أو معاينته المفروض متنفذش حذف مقصود

GET  /products       -> List products
POST /products       -> Create a product
GET  /products/book  -> Show a product

الفرق بين جزء المسار و Query String

في الرابط التالي ال notebook جزء من المسار ممكن يطابق معامل ديناميكي وال page و sort قيم في Query String لتعديل طريقة عرض النتيجة المسار مش اسم ملف بالضرورة

https://example.com/products/notebook?page=2&sort=price

نموذج مبسط للفكرة باستخدام JavaScript

المثال ده محاكاة تعليمية لمطابقة مسارين مش Router كامل ولا خادم HTTP الفكرة إننا بنفحص طريقة الطلب والمسار وبعدها بنختار الاستجابة

function route(method, path) {
  if (method === "GET" && path === "/services") {
    return { status: 200, body: "Services page" };
  }

  if (method === "GET" && path === "/api/status") {
    return { status: 200, body: { online: true } };
  }

  return { status: 404, body: "Not found" };
}

console.log(JSON.stringify(route("GET", "/services")));
console.log(JSON.stringify(route("GET", "/api/status")));
console.log(JSON.stringify(route("GET", "/missing")));
{"status":200,"body":"Services page"}
{"status":200,"body":{"online":true}}
{"status":404,"body":"Not found"}

مثال داخل Laravel

في مشروع Laravel موجود حط التعريفات دي في routes/web.php المسار الأول بيرجع View اسمها services فجهز ملف resources/views/services.blade.php والمسار التاني بيرجع بيانات JSON باستخدام قيمة مأخوذة من الرابط

<?php

use Illuminate\Support\Facades\Route;

Route::get('/services', function () {
    return view('services');
});

Route::get('/products/{slug}', function (string $slug) {
    return response()->json(['slug' => $slug]);
});

لو فتحت /products/notebook هتكون قيمة slug هي notebook المثال بيرجعها للتوضيح بس ومش بيدور في قاعدة بيانات في مشروع حقيقي هتجيب المنتج وتتعامل مع غيابه وصلاحية المستخدم لرؤيته

التوجيه في الواجهة الأمامية

في تطبيقات بتستخدم Router داخل المتصفح علشان تغير الواجهة حسب الرابط من غير تحميل صفحة كاملة مع كل تنقل Vue Router مثال على ده وبيتربط فيه المسار ب Component

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

ليه الرابط يشتغل وقت التنقل ويفشل بعد Refresh

في وضع HTML5 History ممكن المتصفح يطلب المسار مباشرة من الخادم عند تحديث الصفحة الخادم لازم يكون متجهز يرجع نقطة دخول التطبيق لمسارات الواجهة المناسبة مع الحفاظ على مسارات ال API والملفات والتعامل الصحيح مع الصفحات غير الموجودة

أما Hash Routing فبيحط جزء توجيه الواجهة بعد علامة # والجزء ده مش بيتبعت للخادم ضمن طلب HTTP الاختيار له أثر على شكل الروابط وطريقة إعداد الاستضافة

التوجيه مش هو إعادة التوجيه

اختيار Handler داخليا مش لازم يغير عنوان المتصفح أما Redirect فاستجابة بتطلب من العميل يروح لرابط تاني متخلطش بين وجود Route بيخدم صفحة وبين نقل الزائر إلى عنوان مختلف

نقط تراجعها قبل إضافة أي Route

حدد طريقة الطلب والمدخلات والرد المتوقع ومين مسموح له ينفذه وافصل التحقق من البيانات والصلاحيات عن مجرد مطابقة المسار وجرب رابط غير موجود ومدخل غير صالح بدل تجربة المسار الصحيح فقط

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

مصادر للتوسع