Уж коли я затронул тему роутинга, то есть смысл немного окунуться в технические детали, поскольку большинство php-библиотек для роутинга представляются загадочными и сложными не только для новичков, но и опытных специалистов. Проблема здесь в том, что каждый разработчик пытается реализовать свои идеи, которые, как он думает, должны подходить для всех и каждого.

Данный подход делает php-разработки сложными и запутанными. PHP — такой язык программирования, который позволяет решать задачи просто и понятно. Во многих случаях не нужна лишняя обвеска и дополнительный уровень абстракции, которая только запутывает код. Работа с HTTP по какой-то мистической причине, часто обвешивается тонной абстракций, хотя всё крутится вокруг простых вещей.

Каркас приложения

Современное php-приложение строится достаточно просто. Все http-запросы отправляются в одну точку входа — это фронт-контролер. Обычный index.php в корне сайта. ЧПУ организуется в .htaccess. Приведу пример файла из одной своей разработки:

Options +FollowSymLinks
Options -Indexes
DirectoryIndex index.php
AddDefaultCharset UTF-8
 
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . / [L,QSA]
</IfModule>

В прошлой статье я уже рассказывал как это работает: всё передаётся в индексный файл (index.php).

Во фронт-контролере подключаются необходимые php-библиотеки, настраивается автозагрузка классов PSR-4 и определяются базовые константы (об этом я рассказывал в своём telegram-канале, поэтому не буду повторяться), например BASE_DIR, SITE_URL, SITE_PROTOCOL, SITE_HOSTи т.д.

И после этого управление передаётся в точку входа application, то есть там, где непосредственно размещается ваше приложение. Например это будет файл app/bootstrap.php. Уже в этом файле запускается роутинг.

Следует отметить, что во многих php-фреймворках роутер подключается скрыто где-то в дебрях своих библиотек и модулей. Пользователю остаётся только возможность конфигурации через отдельные файлы. Полноценное управление роутером здесь невозможно. И уж тем более сменить его на какой-то свой вариант.

Запуск роутера

Поскольку app/bootstrap.phpявляется точкой входа для приложения, то в нём и размещается роутер.

Роутер — это самый обычный php-класс, который может размещаться как угодно. Главное, чтобы он соответствовал PSR-4.

Первым делом создаём объект роутера. После этого считываем конфигурацию, где хранится массив правил для роутинга, скажем файл app/Config/routes.php.

Как хранить опции и конфигурации я также рассказывал недавно в своём telegram-канале.

Этот массив мы добавляем как правила роутинга. При этом мы можем прочитать и множество других файлов с правилами, для того, чтобы разделить их по модулям своего приложения, а не кидать всё в одну кучу. Правила роутинга суммируются и накапливаются в его объекте.

После этого можно задать специальное правило для случаев, если никакие другие не сработали. Это будет 404-страница, а точнее его класс и метод.

Дальше запускаем роутинг, который сам уже разруливает правила и подключает нужные классы. В некоторых php-фреймворках объект роутера даже именуется как $app, что показывает его основное назначение — запуск приложения.

В коде это выглядит так:

// создание объекта
$route = new \Lib\Router\Router;
 
// подключаем правила из конфига
if ($rules = \Lib\Core\Core::readConfig('routes.php'))
    $route->addRules($rules);
 
// данные для 404-страницы
$route->setNotFound('\Modules\Page404\Page404@index');
 
// run application
$route->run();

Правила роутинга

Конфигурационный файл возвращает массив, где каждое правило формируется тоже как массив. Просто покажу пример в котором это хорошо видно:

return [
    [
        'method' => 'GET',
        'pattern' => '', // home
        'action' => '\Modules\Home\Controller@index',
    ],
     
    [
        'method' => 'POST',
        'pattern' => '', // home
        'action' => '\Modules\Home\Controller@post',
    ],
  
    // contact использует класс Pages
    [
        'method' => 'GET',
        'pattern' => 'contact', 
        'action' => '\Modules\Pages\Pages@contact',
    ],
    
    [
        'method' => 'POST',
        'pattern' => 'contact', 
        'action' => '\Modules\Pages\Pages@contactPost',
    ],
];

Три основных ключа любого правила:

• method — указывает на http-метод (GET, POST, OPTION, MYMETHOD). Любой вариант, можно и свой придумать. Для любого варианта используется ANY.
• pattern — паттерн адреса. Представляет собой обычную регулярку. В роутере можно предусмотреть спецзамены для более простого использования ([:any], [:num], [:segment] и т.д.).
• action — действие. Класс и метод, которые сработают на этот паттерн. Это может быть класс@метод, просто функция (function), либо название функции.

Кроме этого иногда нужно передать в action какие-то данные прямо из правила. В этом случае используется ключ param, где указывается, то что будет востребовано в выполняемом классе. Но, опять же это особые ситуации.

Лично я предпочитаю для конфигурации использовать именно php-массив, но многие роутинги позволяют добавлять эти же самые правила через строчку. Она парсится и добавляется во внутреннее поле объекта уже как положено в массиве.

В общем не важно как именно добавляются правила в итоге они всё равно должны описывать http-метод, URL-паттерн и действие для выполнения.

Метод setNotFound()описывает только action в том же формате.

Логика работы роутера

Запуск роутера происходит через метод run(). Первое, что там происходит — это сравнение текущего URL с паттернами правил. Например это может быть приватный метод match(), который возвращает результат сравнения.

В match()проверяется не только паттерн (это обычная регулярка), но и http-метод. Чтобы это сделать для текущего URL формируется массив его данных, который удобен для дальнейшего использования. Вот что-то такое:

[method] => GET
[method_data] => Array ()
[url] => 
[url_full] => http://сайт/
[query] => 
[url_segment] => Array
   (
      [0] => 
   )
[query_data] => Array ()

Разбор URL в большинстве случаев это не что иное, как данные из $_SERVER. В некоторых случаях ещё используют parse_url()и parse_str()для корректного декодирования адресов. Но в большинстве случаем роутинг любого php-проекта работает именно на этих трёх компонентах. Всё, что сверх этого — бессмысленная абстракция и утяжеление кода.

Когда match()находит совпадение по http-методу и паттерну, он парсит строчку action. На выходе получаем (в run()) массив результата проверки, где уже подключаем файл, выполняем функцию или инициализируем объект указанного класса и выполняем указанный метод.

Если же возникла ситуация, что ни один actionне сработал, то выполняем указанный для 404-страницы метод. Хотя, если и он не найден, то просто ничего не делаем. Роутер может вернуть false, который уже анализируется в app/bootstrap.php.

if (!$route->getResult()) echo '404-page';

Такой вариант позволяет не задавать 404-страницу для роутера.

Задача любого роутера — найти соответствие URL какому-то паттерну и запустить в случае успеха «что-то». Больше в его задачу ничего не входит, поскольку это уже лишнее.

Точно также, как и лишними будут многочисленные функции вроде getPost(), getGet()— возвращающие стандартные $_POSTи $_GET. Разработчики PHP очень упростили задачу по работе с этими http-методами (включая и $_FILES) — подменять их своими функциями — больше смахивает на глупость.

HTTP-методы

В заключении пару слов от http-методах. На практике есть только два варианта: POST и GET. Именно их браузеры и поддерживают, хотя есть некие стандарты, которые предполагают существование других вариантов. Кроме того эти методы завязаны на HTML — в основном это обычные формы, либо Ajax-запросы. Во всех таких случаях, как ни крути, в реальности используется только POST.

Чтобы ничего не ломать, придумали хитрость: в post-запросе отправлять поле _method, который и содержит название http-метода. Для формы это выглядит так:

<form method="POST">
	<input type="hidden" name="_method" value="PUT">
	... прочие данные формы ...
</form>

То есть реальная отправка — POST, но роутер проверят наличие поля _method. Именно поэтому http-метод в php-роутере может быть абсолютно любым.

На этом базируется концепция RESTful и CRUD, где используется один адрес, но разные http-методы. Это указывается в правилах роутера:

[
    'method' => 'POST',
    'pattern' => 'task', // create new task (Create)
    'action' => '\Controller\Task\Task@create',
],
[
    'method' => 'GET',
    'pattern' => 'task', // task show (Read)
    'action' => '\Controller\Task\Task@read',
],
[
    'method' => 'PUT',
    'pattern' => 'task', // update/edit task (Update)
    'action' => '\Controller\Task\Task@update',
],
[
    'method' => 'DELETE',
    'pattern' => 'task', // delete task (Delete)
    'action' => '\Controller\Task\Task@delete',
],

А в форме что-то вроде такого:

...
<button type="submit" name="_method" value="PUT">Update selected</button>
<button type="submit" name="_method" value="DELETE">Delete selected</button>

В зависимости от сложности проекта, создаётся и роутинг. С моей точки зрения лучшим вариантом будет именно свой «велосипед», поскольку он на 100% покроет реальные задачи. Сторонние библиотеки всегда стараются сделать универсальными, а это приводит к тому, что 80% их возможностей просто не используются.