Як визначати вимоги маршруту
Дата оновлення перекладу 2023-06-14
Як визначати вимоги маршруту
Вимоги маршрутів можуть бути використані так, щоб
певний маршрут відповідав тільки за певних умов. Найпростіший приклад
включає в себе обмеження маршруту {wildcard}
так, щоб він відповідав
тільки деяким регулярним виразам:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
// src/Controller/BlogController.php
namespace App\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Routing\Annotation\Route;
class BlogController extends Controller
{
/**
* @Route("/blog/{page}", name="blog_list", requirements={"page"="\d+"})
*/
public function list($page)
{
// ...
}
}
Завдяки вимозі \d+
(тобто "числове значення" будь-якої довжини), /blog/2
відповідатиме цьому маршруту, але /blog/some-string
- не буде.
Оскільки вимоги параметрів - це регулярні вирази, складність і гнучкість кожної вимоги повністю залежить від вас. Уявіть, що домашня сторінка вашого додатка доступна двома різними мовами, ґрунтуючись на URL:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// src/Controller/MainController.php
// ...
class MainController extends Controller
{
/**
* @Route("/{_locale}", defaults={"_locale"="en"}, requirements={
* "_locale"="en|fr"
* })
*/
public function homepage($_locale)
{
}
}
Для вхідних запитів частина URL {_locale}
відповідає регулярному
виразу (en|fr)
.
???? | ????????? |
---|---|
/ |
{_locale} = "en" |
/en |
{_locale} = "en" |
/fr |
{_locale} = "fr" |
/es |
?? ????????????? ????? ???????? |
Note
Ви можете підключити співіставлення маршрутів UTF-8, встановивши опцію
utf8
при оголошенні або імпортуванні маршрутів. Таким чином,
наприклад, .
у вимогах буде збігатися з будь-якими символами UTF-8,
а не тільки з одним байтом.
Tip
Вимоги маршрутів також можуть включати в себе параметри контейнерів, як пояснюється у цій статті. Це може бути корисним, коли регулярний вираз дуже складний і багаторазово використовується у вашому додатку.
Додавання вимог HTTP-методів
На додаток до URL, ви також можете використовувати відповідність у методі вхідного запиту (тобто GET, HEAD, POST, PUT, DELETE). Уявіть, що ви створюєте API для вашого блогу, і у вас є 2 маршрути: один для відображення запису (за запитом GET або HEAD), і один для оновлення запису (за запитом PUT). Цього можна досягти за допомогою такої конфігурації маршруту:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
// src/Controller/BlogApiController.php
namespace App\Controller;
// ...
class BlogApiController extends Controller
{
/**
* @Route("/api/posts/{id}", methods={"GET","HEAD"})
*/
public function show($id)
{
// ... повернути JSON-відповідь з постом
}
/**
* @Route("/api/posts/{id}", methods="PUT")
*/
public function edit($id)
{
// ... edit a post
}
}
Незважаючи на той факт, що ці два маршрути мають ідентичні шляхи
(/api/posts/{id}
), перший маршрут відповідатиме лише запитам
GET або HEAD, а другий - тільки запитам PUT. Це означає, що ви можете відобразити
і змінити запис з одним і тим самим URL, використовуючи окремі контролери для двох
дій.
Note
Якщо не вказано жодних methods
(методів), то маршрут відповідатиме
всім методам.
Tip
Якщо ви використовуєте HTML-форми та HTTP-методи крім GET
і POST
,
вам знадобиться увімкнути параметр _method
щоб зімітувати HTTP-метод.
Див. Як змінити дію та метод форми, щоб дізнатися більше.
Додавання вимог хоста
Ви також можете використовувати відповідність в HTTP хості вхідного запиту. Щоб дізнатися більше про це, див. Як зробити так, щоб маршрут відповідав на засаді хоста у документації компонента Routing.
Додавання динамічних вимог з виразами
Для дуже складних вимог ви можете використовувати динамічні вирази для відповідності будь-якій інформації за запитом. Дивіться Умови маршрутизації.