route php что такое
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 каталог, как он станет доступен по одноименному адресу.
В чем суть роутера на 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
Единая точка входа
Принцип работы единой точки входа очень прост.
Вот и весь принцип единой точки входа. Именно так она работает в популярных 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 аннотаций заключается в том, что Вам не нужно больше создавать дополнительные файлы в которых будут прописываться конфигурации. Все конфигурации находятся прямо перед методом, избавляя нас от необходимости искать их где-то еще. В общем, много говорить не буду, а просто оставлю здесь код. Кстати, в данном примере используется компонент doctrine/annotations, который и ответственен за всю логику парсинга аннотаций.
Сначала создаем файл composer.json:
Далее в этой же папке выполняем команду
Создаем файл index.php, первые строки которого выглядят так:
Далее в этом же файле создаем класс аннотации @Route:
Далее добавляем тестовый контроллер:
/**
* @Route(
* url = «/login»,
* handler = «PageController::login»,
* methods = <"GET">
* )
*/
public function login() <
print __METHOD__;
>
/**
* @Route(
* url = «/article/
* handler = «PageController::article»,
* methods = <"GET">
* )
*/
public function article($id) <
print __METHOD__;
>
public function stub() <
print __METHOD__;
>
>
Класс RouteCollector
// класс собирает все маршруты в массив
class RouteCollector
<
// метод получает на вход строковое имя класса
// который содержит роуты
public function collect($class)
<
// объект класса AnnotationReader из пакета doctrine/annotation
$reader = new Doctrine\Common\Annotations\AnnotationReader();
// загружаем класс в объект ReflectionClass
$refClass = new ReflectionClass($class);
Вызываем все это дело так:
// создаем класс коллектора
$collector = new RouteCollector();
// выводим маршруты
print_r($routes);
Результат примерно следующий:
Array
(
[0] => Route Object
(
[url] => /
[handler] => PageController::index
[methods] => Array
(
[0] => GET
)
[1] => Route Object
(
[url] => /login
[handler] => PageController::login
[methods] => Array
(
[0] => GET
)
[2] => Route Object
(
[url] => /article/
[handler] => PageController::article
[methods] => Array
(
[0] => GET
)
)
)
Вот так можно организовать конфигурацию маршрутов в PHP с помощью аннотаций.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 4 ):
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Как работает 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% их возможностей просто не используются.