<?php
$app->get('/users', function ($request, $response) {
return $response->write('GET /users');
});
Главная содержательная часть в файле index.php — обработчик запроса:
<?php
$app = AppFactory::create();
// Обработчик
$app->get('/', function ($request, $response) {
return $response->write('Welcome to Slim!');
});
Общий принцип работы любого веб-фреймворка отражает архитектуру HTTP. На каждый адрес задаётся обработчик (функция, handler), который выполняет необходимые действия и возвращает ответ. В Slim, все приложение (сайт) представлено объектом класса Slim\App
. Этот объект содержит методы на каждый глагол HTTP: get
, post
, put
и так далее. Эти методы принимают на вход два параметра, первый — адрес (говорят «маршрут»), для которого вызовется обработчик и второй, собственно сам обработчик. Лямбда-функция с двумя параметрами $request
и $response
.
Во фреймворках принято (и это соответствует идеям REST) определять маршрут, как комбинацию метода HTTP и адреса. То есть GET /users и POST /users с точки зрения большинства фреймворков — разные маршруты со своими обработчиками. В этом достаточно просто убедиться, если определить соответствующие маршруты и выполнить к ним запросы с помощью curl.
<?php
$app = AppFactory::create();
$app->get('/users', function ($request, $response) {
return $response->write('GET /users');
});
$app->post('/users', function ($request, $response) {
return $response->write('POST /users');
});
$app->run();
curl localhost:8080/users
GET /users
curl -XPOST localhost:8080/users
POST /users
Перед тем как двигаться дальше, обязательно попробуйте повторить примеры выше в вашей локальной среде, это очень важно для понимания последующего контента.
Первое, что бросается в глаза, у нас всего лишь один входной файл для всех адресов. Пользователь может запрашивать сколь угодно сложный адрес /companies/3/photos5, всё сведётся к запуску файла index.php, а сам адрес становится лишь значением $_SERVER['REQUEST_URI']
.
.
├── site
│ └── public
│ └── index.php
Такой подход имеет название FrontController в противовес подходу, когда каждый адрес (на самом деле маршрут, но об этом чуть позже) фактически отображался на конкретный файл файловой системы. Такой подход называется PageController. В интернете до сих пор встречаются сайты построенные по этой модели, но она давным давно вышла из употребления. Заметить её легко, если вы видите адреса наподобие /users.php
, то почти наверняка в корне сайта лежит файл users.php, отвечающий за обработку этой страницы.
.
├── site
│ └── public
│ └── home.php
│ └── users.php
│ └── companies.php
Во FrontController процесс поиска нужного обработчика называется диспетчеризацией, по аналогии с тем как это слово используется в оффлайн жизни. Пошагово он выглядит так:
До входа во фреймворк:
После входа в сам PHP (именно это и есть диспетчеризация):
$app
(как в примерах в начале урока) с тем что пришло. Он сравнивает комбинацию метода запроса и сам адрес. Этот процесс называется роутингом (или маршрутизацией). А место, где внутри хранятся все добавленные маршруты, обычно называют роутером.Рассмотрим конкретный пример. Возьмём за основу следующий код:
<?php
$app = AppFactory::create();
$app->get('/', function ($request, $response) {
return $response->write('GET /');
});
$app->get('/companies', function ($request, $response) {
return $response->write('GET /companies');
});
$app->post('/companies', function ($request, $response) {
return $response->write('POST /companies');
});
$app->run();
После запуска этого кода, формируется роутер, который содержит в себе три маршрута:
GET /
GET /companies
POST /companies
Теперь предположим, что клиент выполнил такой запрос:
curl -XPOST localhost:8080/companies
Веб-сервер запустил index.php, который проинициализировал объект $app
(помните, что на каждый запрос этот процесс повторяется с нуля?), затем фреймворк сопоставил маршруты и нашёл, что за этот запрос отвечает POST /companies. Далее фреймворк вызвал обработчик, который вернул клиенту ответ: POST /companies.
Интересный вопрос заключается в том, что произойдёт, если фреймворк не обнаружит соответствия? Например, клиент запросит страницу /comments? В такой ситуации, фреймворк берёт управление на себя (по умолчанию) и автоматически отдаёт браузеру ответ 404, то есть говорит о том что страница не найдена. Всегда внимательно смотрите, какие делаются запросы и есть ли подходящие под них ответы, чтобы не мучиться вопросом "почему браузер ничего не показывает". Проще всего увидеть ответ от сервера через консоль разработчика вашего браузера:
Она есть в каждом браузере. Попробуйте открыть её и понаблюдать за процессом загрузки.
Добавьте обработчик в файл index.php, который мы создали в самостоятельной работе предыдущего урока:
<?php
$app->get('/users', function ($request, $response) {
return $response->write('GET /users');
});
Откройте в браузере эту страницу. Убедитесь что на экран вывелся текст переданный в метод write()
.
Вам ответят команда поддержки Хекслета или другие студенты.
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно
Наши выпускники работают в компаниях:
Зарегистрируйтесь или войдите в свой аккаунт