https://habr.com/ru/articles/951326/
Здравствуйте
у кого такая же ситуация как в теме?
ИИ говорит, что надо юзать прокси, чтобы обходить блокировку РКН адреса АПИ api.telegram.org
других решений разблокировать постинг на ПХП в ТГ нет?
Я про условие "если хочет джсон то .... иначе...."
Я пока думаю над этим, нашел эту фичу именно читая этот топик. Раньше я всегда отдельно писал АПИ для возврата JSON, отдельно для браузера
У меня будут еще мобильные приложения и наличие такого ответа сильно упрощает код
Ну собственно пример выше :), на ларавель тоже можно.
Единственное НО. Обычно для апи и веба разные миддлвары подключают. (настройка на уровне маршрутов и групп маршрутов). В контроллер мы попадаем уже через все эти миддлвары. В АПИ, как правило, не нужны сессии и SCRF токен, но нужен JWT... и там тоже тогда надо проверять с чем работаем? Или речь всегда о стейтлес работе?
В плане роутинга мне больше нравится подход как в ларавель. В симфони с его стремлением везде использовать атрибуты (а ранее в phpDoc) мне совсем не заходит. (именно по этому я и сделал больше похожим на лару).
В моем понимании создавая контроллер я не знаю как и зачем он будет использоваться. И на какие маршруты отвечать. Это не ответственность кода контроллера. Это ответственность системы маршрутизации. Если у меня на проекте возникла причина поменять маршруты. (ну условно изменит /api/ на /my_best_api/ - как очень упрощенный частный случай) - то я недолжен лезть в код и проходить все контроллеры.
одни и те же маршруты (а точнее контроллеры) работать с разным типом контента не проблема. Раз уж речь зашла о симфони. тут я покажу сразу в одном примере два маршрута, но суть полагаю понятна - маршрут может остаться и один.
use Symfony\Component\HttpFoundation\Request;use Symfony\Component\HttpFoundation\Response;use Symfony\Component\Routing\Annotation\Route;use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;class BlogController extends AbstractController{ #[Route('/api/blog_create', name: 'api_blog_create')] #[Route('/blog/create', name: 'blog_create')] public function new(Request $request): Response { if ($request->getPreferredFormat() === 'json') { return $this->json([ 'status' => 'success', 'message' => 'Это ответ в формате JSON для API', 'data' => ['id' => 123] ]); } return $this->render('blog/new.html.twig', [ 'message' => 'Это HTML-страница' ]); }}
Но! На мой взгляд этот подход не правильный. Контероллер должен быть тонким. что в твоем, что в моем коде есть лишнее условие, которое решаемо на уровне роутинга. Тут, имхо, нарушение и солид (надо дополнить апи, но трогаем класс, который не имеет отношения к апи), SoC - смешиваем логику ответа условно для непосредственного отображения человеку, и обработки программно, пожалуй KISS. Потом rest обычно подразумевает более широкий спектр статусов ответов... ну понято, что ты привел просто пример, но все же нужная ли это фича? :)
А они все плюс минус одинаково. Блейд так же примерно. На самом деле я хотел пойти несколько иным путем, но именно тут была реплика, что разработчикам было бы удобнее видеть нечто привычное. я подумал подумал и .... но повторюсь пока это проект. У меня база шаблонизатора уже пережила три варианта, и лишь когда осознал направление куда двигаться вернулся к фреймворку - там не хватало например механизмов интеграции модулей удобной (а шаблонизатор это модуль) :)
Единственное у меня в шаблонах будет только то, что внутри body, остальное декларативно описывается и передается (под капотом) генератору... (посмотрим что из этого выйдет в итоге :) - но хочу попробовать)
--- del
А это как-то так, будет движком интерпретатором обработчиком %команда% будет?
$response-> по моему более лучший вариант для тебя
Это варианты для разных уровней.
Нужен и оправдан на проекте шаблонизатор. Значит используем шаблонизатор и шаблоны, соответственно html с тегами шаблонизатора. Шаблонизатор сам взаимодействует с билдером.
Если шаблонизатор на проекте избыточен, но нужно управление статическими файлами -используем только билдер.
Если и билдер избыточен можем совсем по простому. Вот варианты обработчика маршурута (специально, для демонстрации обработчики в виде колбеков (конечно по хорошему они в виде классов реализуются, но можно и так:
// Уже доступно. Возвращается просто строка, готовый HTML. // Преобразуется в HTmlResponse который, при необходимости согласно логике, насыщается, например, заголовками$router->get( '/var1', static fn() => <<<'HTML' <html><head></head><body><ul> <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li> <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li> </ul></body></html> HTML,);// Уже доступно. Возвращается уже готовый HtmlResponse, если есть у нас такая необходимость$router->get( '/var2', static fn() => new HtmlResponse()->setBody(<<<'HTML' <html><head></head><body><ul> <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li> <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li> </ul></body></html> HTML),);// Над этим работаю. $router->get( '/var3', static fn(HtmlBuilder $builder) => $builder->setBody(<<<'HTML' <ul> <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li> <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li> </ul> HTML)->build(),);// Это уже с модулем шаблонизации. HTML где то лежит/формируется согласно правил шаблонизатора$router->get( '/var4', static fn(Templator $templator) => $templator->build(),);
т.е. имеем четыре зарегистрированных url которые будут отдавать одинаковую страницу, но формировать ее разными способами
Точно нет, даже для случая когда пользователь программист если он применяет шаблонизатор. Если же он использует только билдер, то да, тут пишется именно в обработчике маршрута и тут про код по определению
$response->builder->addHeadScript(__DIR__.'/script.js');$response->builder->addCss(__DIR__.'/custom.js');$response->setBody('<div class="desiogn">Hello Alex</div>');
