Что называется после Data Persister на Api-Platform?

Question

Я работаю с Api-Platform 2.5 и Symfony 4.4 (lts).

Я обнаружил платформу API и понимаю, что существует много "перехватчиков", которые перехватывают запросы HTTP:

для GET запросов: поставщик данных, контроллер, процесс сериализации и, наконец, «анонимный процесс», который устанавливает код ответа.

для POST, PUT, PATCH и DELETE: процесс сериализации, поставщик данных, контроллер, хранилище данных и, наконец, «анонимный процесс», устанавливающий код ответа.

Здесь у меня есть хранилище данных:

ProductDataPersister :

namespace App\DataPersister;

use ApiPlatform\Core\DataPersister\ContextAwareDataPersisterInterface;
use App\Entity\Product;

final class ProductDataPersister implements ContextAwareDataPersisterInterface
{
    public function supports($data, array $context = []): bool
    {
        return $data instanceof Product;
    }

    public function persist($data, array $context = [])
    {
        //dd('persist');
        return $data;
    }

    public function remove($data, array $context = [])
    {
        //dd('remove');
    }
}

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

У меня такой вопрос, как мы говорим, что действие удаления с этим кодом никогда не удаляет Продукт, и это то, что я хочу. Но ответ, который я получаю на запрос DELETE, все еще не переопределен и по-прежнему возвращает 204 код состояния ( без содержимого ).

Я хочу переопределить тип ответа. Какой другой слушатель исполняется после Data Persister?

Можно ли переопределить?

Answer 1

Если вы посмотрите на систему событий Api-Platform , становится ясно, что искомое событие, которое вы называете «анонимным процессом», имеет соответствующее имя RespondListener.

Вы можете увидеть здесь точную точку, в которой он устанавливает код ответа.

Самый простой способ переопределить это - зарегистрировать собственный прослушиватель событий. / subscriber , который будет выполнен после этого прослушивателя:

public static function getSubscribedEvents()
    {
        return [
            KernelEvents::VIEW => ['fooMethod', EventPriorities::POST_RESPOND],
        ];
    }

На fooMethod(ViewEvent $event) вы можете получить доступ к объекту ответа доступа ($event->getResponse() и изменить его, или даже создать свой собственный объект ответа (хотя это вероятно, будет даже менее оптимальным).

---

В качестве альтернативы, вы можете украсить @api_platform.listener.view.respond сервис и реализовать свои переопределенные логики c в декораторе.