Symfony как использовать FOSRestBundle

[lowadka]

Думаю в статье стоит упомянуть про параметр:

fos_rest:
    serializer:
        serialize_null: true

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

[php_freelancer]

А вот кстати да! Не подумал сначала почему-то. Вообще нужная вещица — сериализация null.
Добавил в статью, спасибо.

[Fesor]

Ну не сказать что оно особо нужная.

[by25]

Ну не сказал бы, 1С-ники (горите в аду) плачут часто, что нету ключа в json.

[lowadka]

Если говорить в целом про бандл, то он наверное хорош, но если вы делаете исключительно json api, то он очень избыточен, как в скорости работы, так и в количестве кода. В реальном проекте такое:

    /**
     * @param $id
     * @return \Symfony\Component\HttpFoundation\Response
     * @View(serializerGroups={"user"})
     */
    public function getUserAction($id)
    {
        $user = $this->getDoctrine()->getRepository('AppBundle:User')->find($id);

        if (!$user instanceof User) {
            throw new NotFoundHttpException('User not found');
        }

        $view = $this->view($user, 200);
        return $this->handleView($view);
    }

Превратится в такое:

    /**
     * @Common\Annotation\SerializationGroups({"manager_app__user_details"})
     */
    public function detailsAction(Common\Entity\User $entity)
    {
        return $entity
    }

Где вся повторяющаяся логика вынесена во всякие listener`ы и шорткаты

[Fesor]

Ну оно как бы и так выносится спокойно в листенеры и шорткаты, а почему у автора так как приведет — без понятия.

        $user = $this->getDoctrine()->getRepository('AppBundle:User')->find($id);

        if (!$user instanceof User) {
            throw new NotFoundHttpException('User not found');
        }

это вообще из коробки идет в виде ParamConverter

        $view = $this->view($user, 200);
        return $this->handleView($view);

тут опять же непонятно почему бы просто не выплюнуть $user, у нас же все уже описано в аннотациях. Да и одной строчкой это делается.

[BOLTIKUS]

Стоит более подробно написать про группы сериализации. О том что их может быть несколько и это позволяет получать разные поля сущности в разных ситуациях.
Так же можно описать процесс десериализации, опять же группы, парам конвертер для получения и валидации сущностей из запросов клиентов.
И напоследок упомянуть про то как кастомизировать эксепшены через эксепшен врапперы и стратегию именования полей для сериализации.

[Fesor]

Не используйте JMS Serializer. Он привносит больше проблем чем пользы. Есть symfony/serializer на худой конец.

[lowadka]

Какие например? Не ради спора, действительно интересно

[Fesor]

Для начала посмотрим пульс пациента — он мертв. Проект активно не поддерживается уже более двух лет.

1) иногда просто так сериализует массив как хэш-мэпу, лечится кастылями в виде листенеров
2) надо замэпить json на существующий объект — лепим object creator
3) inline — работает только в одну сторону, без возможности задать кастомный префикс. бесполезная фича. В принципе очень много фич работающих наполовину.
4) шаг в право/шаг в лево — пишем свои хэндлеры или листенеры, много лишнего кода, не особо прогнозируется необходимость писать этот код. Много рисков.
5) версионизация API? переименовали пропертю? Пишите свои хэндлеры, мэппингами вы это так просто уже не разрулите.
6) в принципе для тупого CRUD сойдет, но чуть сложнее — и все… приплыли к морю кода. Быстрее руками мэппинги сделать.
7) медленно. У меня были проекты где jms serializer занимал 50% времени генерации респонса.

Лучше брать symfony/serializer. Он в этом плане намного более грамотная штука. Позволяет сделать все то же что и jms serializer но намного более грамотно (за счет выделения процесса нормализации и отделения от сериализации).