Маршрутизация (Routes vs urlrewrite vs D7 Routing)

Основы маршрутизации: что это вообще такое

Маршрутизация — это ответ на вопрос: “какой код обработает этот URL?”

В нормальном приложении роутинг решает сразу несколько задач:

• диспетчеризация: URL → обработчик (контроллер/функция),
• ограничения доступа: кто имеет право на маршрут (авторизация, роли),
• валидация входа: что допустимо в параметрах (/users/{id}),
• соглашения: единый подход к структуре URL (особенно важно для API).

И вот здесь видно ключевое отличие философий:

• Laravel изначально заточен под “приложение”, где роутинг — первый слой.
• Битрикс исторически заточен под “сайт”, где URL часто ведёт на страницу, а бизнес‑логика живёт в компонентах (и URL там вторичен).

Laravel: маршруты, параметры, имена, группы

Где живут маршруты

Типовой расклад:

• routes/web.php — браузерные страницы (сессии, CSRF и т.п.)
• routes/api.php — API (обычно stateless, префикс /api)

Простейший роут:

        use Illuminate\Support\Facades\Route;

Route::get('/ping', function () {
    return 'pong';
});

    

Параметры и ограничения

        use App\Http\Controllers\UserController;
use Illuminate\Support\Facades\Route;

Route::get('/users/{id}', [UserController::class, 'show'])
    ->whereNumber('id');

    

Именованные маршруты и генерация URL

        Route::get('/users/{id}', [UserController::class, 'show'])
    ->whereNumber('id')
    ->name('users.show');

    

Внутри приложения:

        route('users.show', ['id' => 10]); // /users/10

    

Группы: префиксы, неймспейсы, middleware

        use Illuminate\Support\Facades\Route;

Route::prefix('api')
    ->middleware(['throttle:api'])
    ->group(function () {
        Route::get('/status', fn () => ['ok' => true])->name('api.status');
    });

    

Ресурсные маршруты (REST “из коробки”)

        use App\Http\Controllers\PostController;
use Illuminate\Support\Facades\Route;

Route::resource('posts', PostController::class);

    

Да, это “сахар”, но он дисциплинирует URL и методы:

• GET /posts — index
• POST /posts — store
• GET /posts/{post} — show
• PUT/PATCH /posts/{post} — update
• DELETE /posts/{post} — destroy

Middleware в Laravel: где живёт “проверка доступа”

Если маршрут — это “куда попасть”, то middleware — это что должно произойти до/после обработки.

Типовые кейсы:

• проверка авторизации (auth)
• проверка роли/права
• rate limit
• локализация (setLocale)
• логирование/трассировка

Пример:

        use Illuminate\Support\Facades\Route;

Route::middleware(['auth', 'verified'])->group(function () {
    Route::get('/dashboard', fn () => view('dashboard'));
});

    

Практическая мысль: middleware — это механизм, который убирает “if‑ы” из контроллеров и делает правила доступа единообразными.

Bitrix: исторический роутинг (ЧПУ + urlrewrite) и современный D7‑роутинг

“Классика”: ЧПУ и urlrewrite.php

В “типовом” Битрикс‑сайте URL часто связан с файловой структурой:

• /catalog/ — это папка,
• внутри лежит index.php с подключением компонента,
• компонент сам решает, что показывать (раздел/элемент), используя ЧПУ и шаблоны.

В таком мире роутинг часто выглядит так:

1. веб‑сервер отдаёт существующие файлы,
2. всё остальное попадает в обработчик (исторически — urlrewrite.php),
3. urlrewrite.php по таблице правил выбирает “какую страницу/скрипт открыть”.

Плюс подхода: удобно собирать контентные разделы и витрины “компонентами”.
Минус: если вы делаете API или приложение, где URL должен вести не в “страницу”, а в контроллер, то “страничная” модель начинает мешать.

D7‑роутинг: routing_index.php + local/routes/*.php

Начиная с main 21.400.0+ в Битриксе появился D7‑роутинг (официально: Роутинг). В прошлой статье мы уже делали “Hello World” через local/routes/api.php. Здесь разложим по полочкам, как это использовать системно.

Где живут маршруты в Битриксе “по‑взрослому”

• подключение конфигов роутинга — через .settings.php / .settings_extra.php (секция routing)
• файлы маршрутов — только в local/routes/ (это прямая рекомендация вендора)

Минимальный пример local/routes/api.php:

        <?php

use Bitrix\Main\Routing\RoutingConfigurator;

return static function (RoutingConfigurator $routes) {
    $routes->get('/api/ping', static function () {
        return 'pong';
    });
};

    

Группировка и префиксы (API‑гигиена)

Даже если вы делаете 3 endpoint’а, сразу приучайте проект к структуре: префикс /api, версии (/api/v1), единый стиль имён.

Пример идеи (псевдоструктура):

        <?php

use Bitrix\Main\Routing\RoutingConfigurator;

return static function (RoutingConfigurator $routes) {
    // Смысл: держать API отдельно от “сайтовых” URL.
    // Реальные методы группировки зависят от версии main и вашего стека (контроллеры/хендлеры).

    $routes->get('/api/v1/status', static function () {
        return ['ok' => true];
    });
};

    

Важно: в Битриксе вы почти всегда выиграете, если API будет жить в своём пространстве URL, чтобы не конфликтовать:

• с ЧПУ каталогов,
• со страницами сайта,
• с админскими и служебными путями,
• и с историческими правилами urlrewrite.

Чем заменить middleware в Битриксе: Action Filters и “правила до экшена”

В D7‑контроллерах (\Bitrix\Main\Engine\Controller) есть понятие Action Filters — это практически тот же смысловой класс задач, что middleware в Laravel: “что должно быть проверено/выполнено до/после”.

Типовые кейсы:

• требовать авторизацию,
• проверять права,
• ограничивать методы/CSRF,
• валидировать входные параметры.

Псевдопример (идея, без привязки к конкретному проекту):

        <?php

use Bitrix\Main\Engine\Controller;
use Bitrix\Main\Engine\ActionFilter;

final class ApiController extends Controller
{
    public function configureActions(): array
    {
        return [
            'profile' => [
                'prefilters' => [
                    new ActionFilter\Authentication(),
                    // возможны и другие фильтры: CSRF/HTTP methods/permissions и т.п.
                ],
            ],
        ];
    }

    public function profileAction(): array
    {
        return ['ok' => true];
    }
}

    

Практическая мысль: если вы делаете API на Битриксе, то контроллеры + action filters обычно чище и стабильнее, чем “куча хендлеров в local/routes/*.php”.

Типовые ошибки и “грабли” маршрутизации

Кейс A Конфликты URL: сайт vs API

Самый частый класс проблем в Битриксе — когда /api/... внезапно начинает обрабатываться:

• компонентом (потому что ЧПУ поймало шаблон),
• или urlrewrite отдал на страницу,
• или наоборот: D7‑роут перехватил путь, который вы хотели отдать странице.

Кейс B Порядок обработки: “кто первый, тот и прав”

Во всех системах rewrite‑логики порядок важен.
В Laravel это скрыто фреймворком (front controller стабилен), а в Битриксе и окружении — часто “наружу торчит”.

Кейс C Безопасность: “проверки в каждом контроллере”

Если проверки доступа размазаны по коду, вы получите:

• пропуски (endpoint забыли защитить),
• разные правила на похожих URL,
• деградацию качества при росте команды.

Сравнительная таблица: маршрутизация

Шкала (как и раньше): от -2 до +2.