Смотря по тому, какова цель.
Может. Тогда это тоже обработчик.
Т.е. достигнуть "цель обработки" можно при помощи любого метода запроса? Можно выбрать любой метод?
Метод класса, обычная или анонимная функция и т.д. Т.е. то что вызывается в маршрутизаторе при маршрутизации, но не относится непосредственно к нему.
Правильно ли я понял, что с вашей точки зрения можно любые действия "повесить" на GET?
В смысле один обработчик на один адрес (адреса одного формата)? И не более одного?
Вы серьезно? Это распространенная практика. Для приверженцев REST - вовсе "норма жизни".
Обработчик делается исходя из целей обработки, а не исходя из метода запроса.
Т.е. любой обработчик можно "повесить" на любой метод и будет нормально? 😊
Выше уточнил. Смысл был в том, что общий обработчик может быть связан с GET чисто формально по имени, а не быть каким-нибудь специальным default, special, etc.
Что используется узкоспециализированный обработчик для GET, как общий. Хотел даже написать "для GET".
В маршруте можно хранить признак: "сливать" запросы любыми методами в общий обработчик (который может быть связан с GET чисто формально, например метод класса может называться соответствующим образом) или делать дополнительную маршрутизацию по методу запроса в рамках текущего "адресного" маршрута. Т.е. можно выбирать стратегию индивидуально для каждого маршрута.
Правильно, если речь об обработке. Более того, лучше не использовать отдельные адреса для обработки POST-запросов (и др.). Т.е. физически можно использовать один маршрут для одного формата адресов и разных методов запроса. Основные стратегии, которые могут быть реализованы в одном и том же маршрутизаторе для одного формата адресов: 1) использовать общий обработчик для разных методов, "от GET" или специальный; 2) использовать отдельные обработчики для предопределенных методов, а для "неопределенных" - специальный или "системный", который бы сообщал, что "метод не поддерживается" (для этого есть специальный HTTP-код ответа).
Можно использовать упрощенную реализацию только для GET/POST. Это связано с ограничениями браузеров, когда не используется AJAX, и самого PHP. Без специальных расширений PHP, например, не различает PUT- и PATCH-параметры.
Так лом можно было использовать?
В таком случае можно было и молотком, топором или лопатой "решить проблему" 😀
По большому счету здесь даже для catid не нужен подготовленный запрос, т.к. существование категории должно проверяться отдельным "опережающим" запросом. Иногда используют и "ленивые" проверки, но не думаю, что автор достиг такого уровня.
Я этого не увидел. Возможно, осталось в "предыдущей теме".
