Как раз наоборот, роутер всего лишь определяет где, какой контроллер запустить (в $callback описана логика запуска контроллера), а уже за определение наличия данных (POST/PUT) отвечает само приложение, это как допустим DNS (роутер) и веб сервер (приложение). Я считаю что работа с данными это не ответственность роутера.
Конечно понятно что чем больше функциональность системы маршрутизации, тем более гибко её можно настроить (фильтровать udp, перенаправлять tcp), но ИМХО это избыточная ответственность. Пусть твой nginx решает какой виртульный хост ему запускать, а какой проксировать, а не сетевое оборудование хостера.

Почему проблема? Кто то всё равно должен разруливать приоритет, как быть например в CMS, где на одной странице может быть запущено несколько независимых модулей?
Мы же не можем при подключении нового модуля вносить правки в код.
Допустим у нас есть шаблон с тегом {content}, есть админка, где мы указываем что данные модули подключены на данной странице и выводятся в теге {content}, в таком случае приоритетом рулит либо роутинг, либо какой то функционал, который управляет модулями (вкл, выкл, сортировка).
Но в случае с роутингом, можно настроить уникальную сортирову для каждого маршрута, а не просто один модуль выше другого где бы они не подключались.

Я не об этом хотел сказать. Конечно же роутер может определить строку/число, я у себя в роутере использую синтаксис чистой регулярки, но он отвечает именно за маршрут.
То есть он может понять что в URI есть число определённой формы, что при этом там присутствует нужный мне символ и вообще понять всё то, что может понять регулярное выражение, но не POST/DELETE и тд.
Я говорил про проверку данных, пришел ли POST, какого он размера, есть ли при этом необходимые заголовки, права и всё такое, это не его ответственность.
Плюс, это если данному обработчику нужна именно такая проверка, а в других 99% случаях она допустим не нужна, зато нужна другая, которая будет проверять не PUT/DELETE, а допустим время/температуру/права_доступа/юзер_агент, например DELETE может использовать только админ, что тогда роутер решит? Ставить ещё более навороченный роутер?

Я не спорю что это неудобно, мне просто кажется что во первых это раздувает/усложняет/тормозит роутер, во вторых несмотря на дополнительную гибкость это накладывает некоторые "ограничения", проверить POST/GET может, а остальные проверки всё равно будут в обработчике и глубже, в итоге проверка будет раскидана то там то тут, вместо того, что бы возложить эту ответственность на контроллер, который кстати можно через DIC подменять на другой контроллер относительно праздников/фазы_луны и пророчеств ванги.

if (!empty($_POST)) {}

А как тут роутер помогает?
Допустим он определил что по такому URI пришел POST, кто будет проверять что там есть все необходимые поля? Что пароль не меньше 100500 символов?)

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

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2