route php что такое
ЧПУ, роутинг, единая точка входа на PHP
Единая точка входа
Принцип работы единой точки входа очень прост.
Вот и весь принцип единой точки входа. Именно так она работает в популярных CMS вроде WordPress и Opencart, в фреймворках Laravel, Symfony и т.д.
Лично я предпочитаю также перенаправлять их на index.php.
На самом деле на сайтах часто используются 2 точки входа.
Плюсы единой точки входа
Единая точка входа с Apache
Этот файл позволяет переопределять настройки Apache для определённых сайтов и папок.
Также в интернете часто можно встретить другой вариант конфига, отличается он только последней строкой:
Единая точка входа с Nginx
Открываем конфиг домена и внутри секции server прописываем следующее правило:
Простой роутинг
Если единая точка входа настроена правильно, то при заходе по любому несуществующему URL-адресу, например /test должен запуститься файл index.php.
Теперь мы можем написать очень простой роутер, который смотрит на текущий URL и подключает соответствующий скрипт:
Внесём ещё пару доработок. Во-первых, зачастую URL-адреса должны работать вне зависимости от наличия GET-параметров, поэтому вырежем их из URI:
Кроме этого, часто требуется получить доступ к определённой части URL. Для этого разобьём URL на части по слешу:
Теперь мы можем легко добавить маршруты для админки:
Это самый простой вариант роутинга. Не идеальный, конечно, но и не требующий знания регулярных выражений (хотя никто не мешает их использовать) и подключения сторонних библиотек.
При хранении URL адресов в базе данных роутинг будет выглядеть примерно так (реальный код зависит от библиотеки, которую вы используете для взаимодействия с БД):
Роутинг средствами htaccess
Какое-то время назад было популярно прописывать правила роутинга прямо в htaccess, вот несколько примеров:
У этого подхода есть несколько недостатков:
Короче, не используйте этот подход.
Структура URL адресов в админке
Обычно URL адреса в админке формируются по одной из следующих схем:
И сразу рассмотрим простой пример:
Перепишем пример, написанный нами в единой точке входа, под новую схему URL:
Итак, мы берём 1-ый фрагмент URL и проверяем, существует ли в папке pages файл с таким названием.
Как видите, при таком подходе нам больше не нужно прописывать соответствие URL-адресов и PHP-файлов. PHP сам будет искать нужный файл в папке pages по первому фрагменту URL.
Вот так выглядит обработка действий. Мы смотрим на второй фрагмент URL и ищем обработчик этого действия. Для каждого действия (add, update, delete) нужно прописать отдельный блок elseif.
Если вам не нравится вложенная проверка метода, можно сделать иначе. В файле index.php сохраним метод в отдельную переменную:
Затем в products.php меняем заготовку на следующую:
Готово. Да, если вам не нравится, что в коде 2 раза встречается одно и то же действие, только с разными методами, можете использовать немного упрощённую схему URL-адресов из фреймворка Laravel:
Добавление префикса /admin/ в URL
Немного изменим код index.php :
Продвинутый роутер FastRoute
Если вы ищете более серьёзную систему роутинга, рекомендую изучить библиотеку FastRoute. Это очень мощный роутер, идеально подходящий для сложных приложений, особенно если вы используете ООП.
Как работает PHP-роутинг
Уж коли я затронул тему роутинга, то есть смысл немного окунуться в технические детали, поскольку большинство php-библиотек для роутинга представляются загадочными и сложными не только для новичков, но и опытных специалистов. Проблема здесь в том, что каждый разработчик пытается реализовать свои идеи, которые, как он думает, должны подходить для всех и каждого.
Данный подход делает php-разработки сложными и запутанными. PHP — такой язык программирования, который позволяет решать задачи просто и понятно. Во многих случаях не нужна лишняя обвеска и дополнительный уровень абстракции, которая только запутывает код. Работа с HTTP по какой-то мистической причине, часто обвешивается тонной абстракций, хотя всё крутится вокруг простых вещей.
Каркас приложения
Современное php-приложение строится достаточно просто. Все http-запросы отправляются в одну точку входа — это фронт-контролер. Обычный index.php в корне сайта. ЧПУ организуется в .htaccess. Приведу пример файла из одной своей разработки:
В прошлой статье я уже рассказывал как это работает: всё передаётся в индексный файл (index.php).
Следует отметить, что во многих php-фреймворках роутер подключается скрыто где-то в дебрях своих библиотек и модулей. Пользователю остаётся только возможность конфигурации через отдельные файлы. Полноценное управление роутером здесь невозможно. И уж тем более сменить его на какой-то свой вариант.
Запуск роутера
Поскольку app/bootstrap.php является точкой входа для приложения, то в нём и размещается роутер.
Роутер — это самый обычный php-класс, который может размещаться как угодно. Главное, чтобы он соответствовал PSR-4.
Как хранить опции и конфигурации я также рассказывал недавно в своём telegram-канале.
Этот массив мы добавляем как правила роутинга. При этом мы можем прочитать и множество других файлов с правилами, для того, чтобы разделить их по модулям своего приложения, а не кидать всё в одну кучу. Правила роутинга суммируются и накапливаются в его объекте.
После этого можно задать специальное правило для случаев, если никакие другие не сработали. Это будет 404-страница, а точнее его класс и метод.
В коде это выглядит так:
Правила роутинга
Конфигурационный файл возвращает массив, где каждое правило формируется тоже как массив. Просто покажу пример в котором это хорошо видно:
Три основных ключа любого правила:
Лично я предпочитаю для конфигурации использовать именно php-массив, но многие роутинги позволяют добавлять эти же самые правила через строчку. Она парсится и добавляется во внутреннее поле объекта уже как положено в массиве.
В общем не важно как именно добавляются правила в итоге они всё равно должны описывать http-метод, URL-паттерн и действие для выполнения.
Метод setNotFound() описывает только action в том же формате.
Логика работы роутера
В match() проверяется не только паттерн (это обычная регулярка), но и http-метод. Чтобы это сделать для текущего URL формируется массив его данных, который удобен для дальнейшего использования. Вот что-то такое:
Такой вариант позволяет не задавать 404-страницу для роутера.
Задача любого роутера — найти соответствие URL какому-то паттерну и запустить в случае успеха «что-то». Больше в его задачу ничего не входит, поскольку это уже лишнее.
HTTP-методы
В заключении пару слов от http-методах. На практике есть только два варианта: POST и GET. Именно их браузеры и поддерживают, хотя есть некие стандарты, которые предполагают существование других вариантов. Кроме того эти методы завязаны на HTML — в основном это обычные формы, либо Ajax-запросы. Во всех таких случаях, как ни крути, в реальности используется только POST.
На этом базируется концепция RESTful и CRUD, где используется один адрес, но разные http-методы. Это указывается в правилах роутера:
А в форме что-то вроде такого:
В зависимости от сложности проекта, создаётся и роутинг. С моей точки зрения лучшим вариантом будет именно свой «велосипед», поскольку он на 100% покроет реальные задачи. Сторонние библиотеки всегда стараются сделать универсальными, а это приводит к тому, что 80% их возможностей просто не используются.
Схема работы сайта
Запос пользователя в адресной строке поступает в Front Controller где он обрабатывается с помощью роутера (маршрутизатора) в соответсвии с нашими маршрутами (роутами) прописанными в отдельном файле. Здесь же определяется какой контроллер и какой его метод (экшен) будет обрабатывать данный запрос. Уже назначенный контролер будет взаимодействовать с БД (базой данных) для получения необходимой информации и вызывать соответствующий файл представления (вид) для передачи пользователю запрашиваемой информации.
Для того, чтобы понять как это работает, лучше всего представить все в виде такой схемы:
Создаем файловую структуру сайта:
Папки:
Файлы:
В общих настройках мы задали отображение ошибок. Это нужно нам. но не посетителям, поэтому при завершении работ с сайтом, отладке и размещении на хосте, эти строки нам нужно будет изменить. Эта информация может испугать законопослушных и неопытных посетителей сайта, или может быть использована злоумышленниками для взлома сайта.
Для проверки содержимого константы ROOT (полный путь от корня файловой системы), мы можем вывести переменную ROOT следующим образом:
Соединения с БД на этом этапе мы выполнять не будем и вернемся к нему позже.
B нем пропишем следующий строки :
Таким образом мы запустили наш Router и передали ему управление
Router
В папке config создадим для этого файл routes.php
Здесь мы и разместим наши роуты в виде массива:
routes.php
Здесь мы сами решаем, какой метод и какой контроллер будет обрабатывать наш запрос. Делаем это мы на этапе разработки нашего сайта.
Теперь наша задача заставить наш Router прочитать маршруты и помнить их на время выполнения кода.
В конструкторе пишем две строки:
Теперь в наше свойство попадет нужный нам массив.
Для того чтобы проверить все ли у нас подключилось и правильно работает мы в методе run() сделаем распечатку массива : print_r($this->routes);
Получим такое сообщение на сайте :
Array ( [news] => news/index [products] => product/list ) It is file Router.php
Все конечные версии вы можете посмотреть на Гугл Диске
Файл Router.php на данный момент полностью: ЗАДАЧА 3
Теперь нам нужно реализовать метод run(). Это та часть, которая отвечает за анализ запроса и передачу управления
Получение запроса
Файл Router.php на данный момент полностью:
Файл Router.php на данный момент полностью:
Метод getURI() мы сделали приватным, тем самым применили инкапсуляцию, потому как обращаться к этому методу мы планируем только из класса Роутер
Еще раз проверяем. Должно все работать точно так же как и в прошлый раз.
Проверить наличие такого запроса в файле routes.php
Файл Router.php на данный момент полностью:
Файл Router.php на данный момент полностью:
Перезагружаем страницу и видим:
Для проверки выводим +. То есть если наш запрос в адресной строке будет совпадать с роутами то увидим на странице +.
Сохранили изменения в файле. Заходим на сайт, перезагружаем и получаем:
Причем, если теперь вы введете в строку запроса значение несоответствующее нашим роутам (‘ news ‘ => ‘news/index’,’ products ‘ => ‘product/list’ ), то ничего не увидите на сайте.
Обратите внимание, что в качестве разделителей в патерне «
» я использовал тильду, так как в нашем патерне могут содержаться слэши- ‘/’ например при таком адресе страницы (‘ news/archive’ => ‘news/archive’). Файл Router.php на данный момент полностью:
Идем на страницу сайта, вводим запрос (существующий) и получаем:
Определяем какой контроллер и экшен обрабатывают запрос
Результат вы можете увидеть на скриншоте, а код файла Router.php ниже
Файл Router.php на данный момент полностью: ‘; > > > >
В результате мы получили два элемента, первый относящийся к контроллеру и второй к экшену
Теперь мы можем получить имя контроллера:
теперь нам остается сделать заглавной первую букву в названии контроллера функцией :
$controllerName = ucfirst($controllerName);
И теперь можно сохранить и проверить наш сайт.
Таким образом мы получили контроллер. Точно так же мы получаем и наш экшен, с той лишь разницей, что экшен имеет свой стиль наименований (с добавление вначале слова action, чтобы отличать их от других методов класса.
Файл Router.php на данный момент полностью:
Теперь нам сталось подключить нужный класс, создать его экземпляр и вызвать для определенного класса свой метод.
Вначале нам нужно создать наши контроллеры.
Далее мы непосредственно подключаем его, предварительно проверяя существует ли он?
Все необходимые действия в виде анализа запроса и подключения нужного файла мы выполнили
Это позволило нам убедиться, что зaпущенн нужный нам метод. Точно тоже мы проделаем и с другим контроллером
Теперь если мы зайдем по другому адресу, мы получим уже совсем другой контроллер с новым экшеном. Если мы зайдем по адресу, которого нет в таблице наших маршрутов (роутах) то мы не получим ничего.
Все файлы проекта можно посмотреть на Гугл Диске
Далее Модель, Представление и усовершенствования класса Роутер
1 комментарий:
В чем суть роутера на php?
1. Здесь пугают всякими контроллерами, ларавелями. Давайте жить проще. Для начала дадим определение модному слову роутер. Это маршрутизатор. Что делает маршрутизатор? Правильно. Обрабатывает маршруты, являясь связующим звеном. Маршрутом для web сайта принято считать метод запроса [ GET, POST, PUT и другие ] и компоненты URI.
Но для определения маршрута может браться любая другая информация передаваемая серверу, определение выше это лишь наиболее употребляемые параметры.
Сама работа, как правило проста: от клиента приходит запрос, маршрутизатор перебирает все заданные ему пути до первого совпадения. При совпадении вызывается определенная вами функция, которая возвращает ответ клиенту.
2. Он необходим, если в приложении одна точка входа, когда любой запрос приходит на один файл.
На практике используют более сложные маршрутизаторы, у которых гораздо большие возможности.
4. Обойтись без него можно. Если каждая страница в вашем приложении будет являться отдельным файлом, который отвечает за отдачу информации.
Это олдскульная структура, в новых проектах почти не применяется.
Станислав Почепко очень даже делают, все зависит от требований системы.
Роутер следует расценивать, как удобство, но за любое удобство мы платим производительностью. Бремя маршрутизатора можно переложить на web server, а на dns делают роутинг по поддоменам, вопрос был по php роутинг. Чем меньше будет маршрутов, тем быстрее клиент получит содержимое.
При разделении отвественности можно один большой сервис поделить на микросервисы, каждый со своим API, и у каждого будет своя маршрутизация.
а если я пишу к примеру по «олдскулу», то это плохо?
Самый простой способ разобраться в работе приложения на php это поставить xdebug и пройтись по всем вызываемым функциям.
Пишите код, документируйте его, тестируйте его, выкладывайте, просите других анализировать.
Что до фреймворков, многие действительно упрощают жизнь и ускоряют на начальном этапе разработки до выхода в релиз, но только если вы их знаете. Другие фреймворки пытаются выйти на уровень Enterprise. С ростом нагрузки начинаются проблемы у обоих типов, либо фреймворк выкидывается и пишется свое приложение, либо его переделывают под свои нужды, этот выбор уже больше зависит от бюджета.
а можно ли на все это «забить»
Валентин Шапкин для этого разве нужно разрешение?
Есть разные пути, но это уже полемика.
Чтобы подобные безобразия пресечь на корню, принято функциональные блоки выносить в отдельные «модули», и подгружать на конкретный запрос только их, в купе с ядром и стандартными библиотеками (что по сути можно назвать «фреймворк»).
Так вот, чтобы ядро могло разрулить на какие запросы какие функциональные блоки (контроллеры) подгружать для обработки этих самых запросов, логика маршрутизации и выносится в роутер.
Если роутер не получил название экшена и.или модуля, то подставляется default, если по указанному пути файл не обнаружен, то выдается 404. Предельно просто и прозрачно, и всегда наверняка знаешь где и что лежит и как называется и почему.
Подобный подход практикуется в JavaScript фреймворке Ember.JS, под подходом я подразумеваю весьма жесткие соглашения относительно структуры и именования папок, и файлов проектов.
Шаблоны в моих проектах точно так же находятся в строго определенных местах и подключаются экшенами автоматически, если тип их выдачи HTML, иначе генерится JSON, или что-то еще, имеется несколько конвертеров на выходе, подключается тот, который запросил экшен.
PHP-роутинг (Routing) для новичков
Роутинг — это маршрутизация: входящий URL разбирается специальным образом и по его результату выполняется определенный код. С роутингом напрямую связано понятие ЧПУ (человекопонятные урлы), которое позволяет исключить в адресах сложные параметры. Например вместо http://сайт/admin/new-page пришлось бы использовать http://сайт/admin.php?action=new-page
Любой входящий URL на сервере разбирается по единому стандарту. Полностью приводить документацию не буду (см. как пример функцию parse_url), важно лишь понять, что в адресе передается параметр path (путь на сервере), которого на сервере реально может не быть. Например в адресе http://сайт/admin каталога admin реально может не существовать.
Чтобы исключить такой вариант, серверу указывается, что для всех несуществующих каталогов и файлов, подключать php-файл (обычно index.php ).
Тут главная строчка с RewriteRule — именно она определяет шаблон входящего адреса (в примере это регулярное выражение) и что с ним делать. В данном примере будет подключен index.php с параметрами после слэша.
Похожий вариант, только чуть короче, от WordPress:
Здесь принудительно добавляется query-параметр page.
Еще один распространенный вариант (пожалуй самый «типовой»):
Все эти RewriteRule-правила делают простую вещь: как бы «преобразуют» входящий адрес в набор query-параметров. Например адрес http://сайт/admin превратится в http://сайт/index.php?admin
Если это какой-то подкаталог, то он указываетс в RewriteBase и как путь к php-файлу. Например каталог на сервере route :
Если в index.php разместить
Существуют несколько принципиально разных подходов в организации роутинга. Наиболее популярный подход — это когда в адресе передаётся «действие», которое описывается через php-класс. Такой подход хорошо описан в CodeIgniter:
Это сильно утрированный пример, но он хорошо показывает соответствие адреса и php-класса.
Другой вариант похожий, но используется не классы, а функции.
То есть функция — это первый сегмент, а остальные выступают уже как парметры. Встречается более «продвинутый» вариант.
То есть имя функции строится по сегментам URL.
Третий, тоже распространенный вариант — адрес указывает на подключаемый файл.
Здесь все файлы хранятся в каталоге pages и подключаются только если реально существуют. Если файла нет, то подключается предопределенный 404-файл.
Если сайт представляет собой сложный проект, то как правило используют роутинг на основе php-классов. Так его проще поддерживать и развивать. Если же сайт состоит из небольшого количества страниц, то как правило используют подключаемые файлы, где один файл — это одна страница.
Строго говоря, роутинг «на классах» тоже использует «файловое» подключение. Вначале подключается файл с кодом класса, а уже после этого выполняется сам класс.
В задачу роутинга входит не только необходимое «действие», но и валидация входящего адреса и его лексический разбор.
Свой «велосипед» не изобретал только ленивый, но я отмечу довольно известный FastRoute, который вобрал в себя наиболее типичные решения.
В первую очередь это использование регулярных выражений при задании правил, например:
Примерно такой же подход используется и в роутинге CodeIgniter.
То есть входящий адрес должен соответствовать шаблону и только в этом случае он «сработает».
В FastRoute реализована поддержка POST и GET-запросов. Такая возможность интересна, хотя на больших проектах такие вещи лучше делать на уровне самого «действия». Но это уже тонкости. Про эту библиотеку я упоминаю в первую очередь из-за того, что она достаточно популярна и уже используется в нескольких интересных проектах: Slim и Lumen.
Для небольших проектов, конечно же, FastRoute будет избыточна, поэтому можно ограничиться вариантом попроще, да и мозги потренировать. 🙂
Весь код в 2 строчки:
Это простой роутинг для простых проектов. Достаточно создать в content каталог, как он станет доступен по одноименному адресу.