Зачем нужен fosrestbundle в symfony?

Question

[Sergei Abramov]

Добрый вечер!
Раньше писал на Yii2. Сейчас хочу написать REST-приложение на symfony, изучаю примеры. Всякие уроки и примеры в сети довольно простые, где-то используется JsonResponse, а где-то используется доп.библиотека fosrestbundle. Но вот нигде не объясняется, нафига она нужна, раз можно штатными средствами все сделать? Если бы она была не нужна - ее бы не существовала, но она есть. Можете объяснить для чего она? В каких случаях ее использовать, а в каких нет?

Answer 1

[Flying]

FOSRestBundle упрощает создание REST endpoints, преобразовывая имена методов в роуты + беря на себя ещё ряд базовых функций по упрощению создания REST API на Symfony. К примеру вам ведь нужно выдавать нормальные ответы в случае ошибок и exceptions, а ошибки, они ведь очень разные бывают. Неприятно когда у тебя вроде бы REST API, а он вдруг начинает HTML рендерить.

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

В целом FOSRestBundle не особо большой, в экосистеме Symfony есть гораздо более мощные решения для создания API

Comments

[Daria Motorina]

Вы пользовались API Platform?) FOSRestBundle как-то слаб по документации, API Platform больше и сложнее, но тоже нужно вникать, как ею пользоваться

[Flying]

Daria Motorina, Пока не было необходимости, но в целом у них основная идея в почти полностью автоматической генерации crud для entities c поддержкой разных форматов api. Выглядит заманчиво и, думаю, вполне себе работает.

FOSRestBundle довольно быстро раскапывается отладчиком, документация там не очень, согласен

[BoShurik]

Flying, от FOSRestBundle только генерация ошибок и нужна в итоге. Роутинг какой-то магический получается, и в случае, если надо что-то кастомное - только мешает. При том, что роутинг аннотациями такой же понятный, если не понятней, и гораздо более гибкий.

P.S. Если не ошибаюсь, то в последних версиях симфони достаточно прописать у роута

api_controllers:
    resource: ../../src/Controller/Api
    defaults:
        _format: json

и никакого html уже не придет

[Flying]

BoShurik, Согласен, я тоже в итоге от него отказался, но автор вопроса спрашивал что это и с чем едят, а поскольку документация у bundle'а оставляет желать лучшего - решил ответить.

[Николай Егоров]

А возвращать html в json'е частая (допустимая?) практика или нет? Я имею ввиду, что помимо каких то статусов возвращать и html код, и все это упаковать в json в ответе.

[Flying]

Николай Егоров, В целом никто не запрещает так делать, но выглядит это довольно странно, хотя задачи бывают разные, возможно в каких-то специфических случаях это может быть необходимым. Другое дело что если в ответе только html, упакованный в json - то возникает закономерный вопрос не проще ли просто вернуть html?

[Николай Егоров]

Flying, моя ситуация следующая. На странице -/+ 10 блоков с одинаковым, подгружаемым при скролле контентом. Если подгружать каждый из них отдельным запросом, то это для каждого запроса будет инициализироваться PHP, запускаться Symfony, соединение с БД. Поэтому я решил делать 1 запрос на сервер за всеми этими html данными сразу (при первом обращении), получая их в json формате:

{
...
'block-id': 'Html code',
...
}

Что скажете?

[Flying]

Николай Егоров, А вам в этом случае не логично сразу весь этот html на странице размещать? Опять же, инициализация PHP - не самая дорогая операция в случае того же php-fpm т.к. worker'ы уже в памяти, а в случае 7.4 и preloader'а - ещё и почти весь код сразу в памяти и откомпилирован. Соединяться с базой необязательно, та же Doctrine вполне умеет в lazy подключения и, если вы в базу не полезете - то и соединения не будет. А дальше вопрос в том как у вас организовано кэширование, никто не мешает отдавать данные из кэша сразу в обработчике kernel.request, в этом случае дело даже до контроллера не дойдёт.

В целом в Symfony при нормальной настройке вполне можно получить время ответа в пару десятков миллисекунд, но конечно нужно ещё и остальные компоненты запроса учитывать, тот же roundtrip до сервера. Если у вас сервер в Штатах, а клиент в Австралии - то вам оптимизация не сильно поможет в любом случае :)

Также не стоит забывать о том что рендерить шаблоны можно и на клиенте, тот же handlebars можно взять, да или прямо целый twig если необходимо, хотя на клиенте он и будет overkill'ом. В этом случае достаточно передавать только данные.

[Николай Егоров]

Flying, спасибо за ответ! Есть над чем подумать)

[Sergei Abramov]

В итоге решил делать без этой библиотеки, так возможности какие-то сомнительные у нее. Добавил errorHandler для отлова ошибок, и заворачиваю их в читабельный json-response. А больше вроде ничего и не надо.