Dynamic route — URL yo‘lining bir qismi oldindan aniq qiymat emas, parametr sifatida qabul qilinadigan marshrut. Masalan, /users/:id yoki /articles/[slug] bitta route ta’rifi orqali ko‘plab foydalanuvchi va maqola manzillarini qayta ishlaydi. Router real URL’dan parametrni ajratib, mos handler, sahifa yoki ma’lumot yuklash funksiyasiga uzatadi.
Parametr turlari
Path parameter resurs identifikatorini ifodalaydi: /products/42. Query parameter filter, sort va pagination kabi ixtiyoriy holatga mos: /products?category=book&page=2. Catch-all route bir nechta segmentni ushlaydi, masalan hujjatlar daraxtidagi /docs/*path. Optional segment qulay bo‘lsa-da, bir-biriga mos keladigan route’lar noaniqligini oshirishi mumkin.
Router priority aniq belgilanadi. /users/new manzili /users/:id bilan to‘qnashsa, static route odatda oldin tekshiriladi yoki parameter pattern bilan cheklanadi. Case sensitivity, trailing slash va percent-decoding server hamda client routerda bir xil bo‘lishi kerak.
Parameter resolution
Router topgan qiymat hali ishonchli obyekt emas. id integer formatiga parse qilinadi, slug ruxsat etilgan uzunlik va belgilar bo‘yicha tekshiriladi. Database’dan resurs topilmasa 404 qaytariladi. Mavjud, lekin foydalanuvchiga ruxsat etilmagan obyekt uchun 403 yoki ma’lumot oshkor bo‘lishini cheklash maqsadida 404 siyosati tanlanishi mumkin.
Path parameter’ni to‘g‘ridan-to‘g‘ri fayl yo‘liga qo‘shish directory traversal xavfini yaratadi. SQL so‘rovida parametrizatsiya ishlatiladi. URL decode bir marta, aniq qatlamda bajariladi; ikki marta decode qilish filterdan o‘tgan %252e kabi qiymatni keyin xavfli segmentga aylantirishi mumkin.
Server va client routing
Server-side framework dynamic route’ni handlerga bog‘lab, HTML yoki API javobi beradi. SPA router esa shu parametr asosida component tanlaydi va API so‘rovini boshlaydi. Client authorization nazorati faqat ko‘rinishni boshqaradi; server endpoint har safar resursga ruxsatni tekshiradi.
Server-side rendering frameworkida route parameter build vaqtida ma’lum bo‘lsa sahifa statik yaratilishi mumkin. Katta yoki o‘zgaruvchan ro‘yxat request vaqtida render qilinadi yoki incremental revalidation ishlatadi. Fallback holati yangi slug birinchi marta kelganda loading, blocking yoki 404 xulqini belgilaydi.
URL dizayni
Barqaror, inson o‘qiydigan slug ulashish va qidiruv uchun qulay. Biroq nom o‘zgarganda slug ham o‘zgarsa eski havola sinadi; redirect jadvali yoki o‘zgarmas ID qo‘shish yechim bo‘ladi. Bir resursning bir nechta URL varianti canonical URL bilan birlashtiriladi.
Parameter maxfiy ma’lumot saqlash joyi emas. URL browser history, analytics, proxy log va Referer header’da paydo bo‘lishi mumkin. Token va shaxsiy identifikator zarur bo‘lmasa URL’ga qo‘yilmaydi. Signed URL vaqt va amal doirasi bilan cheklanadi hamda loglarda maskalanadi.
Sinov
Route testlari normal qiymat bilan birga bo‘sh, juda uzun, noto‘g‘ri encoding, reserved belgi va overlapping patternlarni qamrab oladi. Back-forward navigation, direct deep link va refresh client router uchun tekshiriladi. Observability route template’ni metric label sifatida ishlatadi; real ID label qilinsa cardinality keskin oshadi.
Lokalizatsiyalangan route
Til kodi path boshida bo‘lsa, masalan /uz/articles/..., router qo‘llab-quvvatlanadigan locale’ni tekshiradi va noma’lum kodni default deb jim qabul qilmaydi. Tarjima qilingan slug foydalanuvchiga qulay, ammo bir maqolaning tillararo bog‘lanishi o‘zgarmas content ID bilan saqlanadi. hreflang, canonical va redirect qoidalari har lokalizatsiyalangan variant uchun izchil yaratiladi.
Slug’da Unicode ruxsat etilsa normalizatsiya va percent-encoding bir xil qo‘llanadi. Vizual bir xil, bayt jihatdan boshqa slug duplicate route yaratmasligi kerak. Database unique constraint canonical shaklga asoslanadi, display matni esa original ko‘rinishni saqlashi mumkin.
Bog‘liq tushunchalar
Routing, URL parameter, Path parameter, Query string, Client-side routing, Server-side rendering, Slug