Маршрути (routes) — це карта сайту для Laravel. Вона відповідає на просте питання: коли користувач відкрив певний URL, який код має виконатися. Якщо маршрути організовані нормально, проєкт читається і масштабується. Якщо маршрути написані хаотично, ти починаєш ловити 404 “на рівному місці”, дублювати URL, плутати методи і підмішувати доступи прямо в контролери.
У Laravel маршрути лежать у папці routes, і ключові файли для старту — web.php і api.php. Різниця між ними не “для галочки”, а практична. web.php призначений для HTML-сторінок і працює з сесіями, cookies та CSRF, тобто підходить для форм і адмінок. api.php призначений для API: зазвичай без сесій, з токенами, з іншими middleware і часто з префіксом /api. Якщо новачок переплутає ці файли, він отримає типові проблеми: 419 на формах, або навпаки — зайві сесії там, де треба чистий API.
Починати треба з найпростішого маршруту, щоб відчути механіку. У routes/web.php можна зробити тестовий маршрут, який повертає сторінку або текст. Далі ти розумієш: URL, метод і “куди веде” — це три речі, які завжди мають збігатися. У реальному проєкті замість анонімних функцій ти майже завжди ведеш маршрут у контролер, бо так код структурується.
HTTP-метод у маршруті — це частина договору. Якщо ти відкриваєш сторінку в браузері, це майже завжди GET. Якщо ти відправляєш форму “створити”, це POST. Оновлення — PUT або PATCH. Видалення — DELETE. Коли ти плутаєш метод, Laravel може видати 404 або “Method Not Allowed”, і новачок думає, що “маршрут не працює”, хоча проблема банальна: не той метод.
Далі важлива тема — групи маршрутів. Група — це спосіб сказати: “усі маршрути в цьому блоці мають спільні правила”. Спільні правила — це префікс URL, middleware, простір імен, іменування. Якщо ти будуєш адмінку, ти не хочеш писати для кожного маршруту окремо middleware('auth') або префікс /admin. Ти робиш одну групу, і в ній всі маршрути автоматично підпадають під одні й ті самі обмеження.
Префікс — це частина URL, яка додається до всіх маршрутів у групі. Наприклад, ти робиш адмінку під /admin, і тоді сторінка новин буде /admin/news, сторінка ресурсів — /admin/resources і так далі. Це дає порядок і прогнозованість: ти одразу бачиш, до якої “зони” належить маршрут. Без префіксів новачки роблять кашу, де адмінські URL змішані з публічними, і потім важко розібратися з доступами.
Окрім префікса, групи часто мають middleware. Наприклад, для адмінки це мінімум auth, а в системах з правами — ще й middleware з permission. Правильний підхід такий: доступ у зону обмежується групою, а більш тонкі права на конкретні дії перевіряються вже на рівні policies або окремих middleware. Так ти не забуваєш захист у кожному методі контролера, бо він вже стоїть на вході.
Named routes — це те, що новачки недооцінюють, а потім страждають. Named route — це ім’я маршруту, яке дозволяє генерувати посилання не через “жорсткий” URL, а через назву. Чому це важливо: URL змінюються, а назви можуть залишатись стабільними. Якщо ти завтра змінюєш /admin/news на /admin/articles, а у тебе всюди в Blade написано “/admin/news”, ти будеш правити десятки файлів і ловити баги. Якщо у тебе named routes — ти змінюєш маршрут один раз, і посилання не ламаються.
Для named routes важлива дисципліна неймінгу. Коли ти робиш групу, ти можеш задати “name prefix”, наприклад admin.. Тоді маршрути будуть мати імена на кшталт admin.news.index, admin.news.store, admin.resources.index. Це читабельно і дає чітку структуру. У великих проєктах саме імена маршрутів стають “мовою” навігації: у Blade ти завжди бачиш, куди веде кнопка.
Окремо варто розуміти різницю між явними маршрутами і resource routes. Resource routes — це скорочення для CRUD: одним рядком ти реєструєш набір маршрутів для index/create/store/show/edit/update/destroy. Це ідеально для адмінок, де багато стандартних сутностей. Але дисципліна така: ресурсні маршрути — для типового CRUD, а нестандартні дії краще робити окремими маршрутами з чіткими назвами, щоб не ламати стандарт.
API-маршрути в routes/api.php мають свою специфіку. Зазвичай вони повертають JSON і працюють без сесій, а авторизація йде через токени. Для новачка важливо запам’ятати: API — це не “інша папка для маршрутів”, а інший контракт. Там важливі статуси 200/201/204/401/403/422, структура відповіді і стабільність. Якщо ти будуєш фронтенд, який ходить у бекенд, API стає основою інтеграції.
Типові помилки з маршрутами повторюються у всіх. Перша — плутанина між web і api, що дає 419 або проблеми з cookies. Друга — відсутність named routes, через що посилання ламаються при будь-якій зміні URL. Третя — відсутність груп і префіксів, через що доступи і структура адмінки стають хаосом. Четверта — неправильні HTTP-методи, які виглядають як “Laravel не бачить маршрут”.
Перевіряти маршрути треба не “на око”, а інструментом. Команда php artisan route:list показує всі маршрути, їх методи, URL, імена і middleware. Це твій швидкий спосіб знайти, чому 404: маршрут не зареєстрований, або він інший, або ти б’єш не тим методом. Якщо новачок навчиться користуватися route:list з першого місяця, він перестане панікувати.
Висновок: маршрути — це дисципліна, яка визначає, чи буде проєкт масштабуватися. web.php — для сторінок і форм із сесіями та CSRF, api.php — для JSON і токенів. Групи і префікси дають порядок і контроль доступів, а named routes захищають від “поломки” посилань при зміні URL. Якщо ти зробиш це стандартом одразу, наступні модулі будуть додаватися швидко і без хаосу.
