How to disable IRI generation for API Resource when normalizing

[andersmateusz]

Hey, I have encountered following problem when normalizing data in my Symfony app where I use API Platform as bundle. I have 'File' entity registered as API resource. When invoking follwing code:

<?php

declare(strict_types=1);

namespace App\Controller;

use App\Entity\Client;
use App\Entity\Complaint;
use App\Entity\File;
use App\Repository\ClientRepository;
use App\Repository\FileRepository;
use App\Service\AzureBlobServiceAdapter;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryParameter;
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Serializer\SerializerInterface;

#[Route('/storage')]
final class StorageController extends AbstractController
{
    public const DEFAULT_CONTAINER_NAME = 'files';

    #[Route('/store', name: 'app_storage_store', methods: ['POST'])]
    public function store(Request $request, AzureBlobServiceAdapter $azureBlobService, SerializerInterface $serializer, ClientRepository $clientRepository): JsonResponse
    {
        $file = new File();
        $normalize = $serializer->normalize($file);

I get an error: 'Unable to generate an IRI for the item of type "App\Entity\File"'. In general it happens when I want to normalize API resource that is not persisted yet and does not have id issigned.
Now the questions are:
How to disable IRI generation in normalization context (if possible)?
How to disable linking API docs in response header for routes that are not API platform routes?
Can I define in API Platform which are and which are not API routes (for example all routes that start with prefix '/api' should return docs and rest of them not)?
Why API Platform interferes in Symfony serialization process?

Thank you for your response in advance.

[soyuka]

How to disable IRI generation in normalization context (if possible)?

genId: false or custom normalizer

How to disable linking API docs in response header for routes that are not API platform routes?

By not using API Platform but a controller ? If you really want to you can override the AddLinkProcessor or even delete any Link header before the response but there's no configuration for that yet.

Can I define in API Platform which are and which are not API routes (for example all routes that start with prefix '/api' should return docs and rest of them not)?

By not using API Platform but a controller ?

Why API Platform interferes in Symfony serialization process?

It shouldn't.

[andersmateusz]

I've figured out that Api Platform changes priority of normalizers so ApiPlatform\Serializer\ItemNormalizer has higher priority than Symfony\Component\Serializer\Normalizer\ObjectNormalizer. And I do not see any way to change this by providing context. This is supportsNormalization method of ApiPlatform\Serializer\AbstractItemNormalizer:

    public function supportsNormalization(mixed $data, string $format = null, array $context = []): bool
    {
        if (!\is_object($data) || is_iterable($data)) {
            return false;
        }

        $class = $context['force_resource_class'] ?? $this->getObjectClass($data);
        if (($context['output']['class'] ?? null) === $class) {
            return true;
        }

        return $this->resourceClassResolver->isResourceClass($class);
    }

Workaround for me is to use Symfony\Component\Serializer\Normalizer\ObjectNormalizer directly or to construct my serializer by providing normalizers argument.

Returning to the subject of disabling linking docs in response header it seems that whenever Content-Type: application/json is requested then link to Api Platform docs is added to header in kernel response event listener. Generally I have one backend both for admin app and also for client app. Admin app is server-side rendered and there are some AJAX requests, but it is not in any way connected to Api Platform. I would rather have separation of concerns, but is not strict requirement.

genId normalization context set to false does not cause disabling generation of IRI and I do not see this in normalizers code as well.

Thank you for your reponse :)

[soyuka]

what version do you use ? you can also override our service with yours to get rid of priority issues

[andersmateusz]

            "name": "api-platform/core",
            "version": "v3.1.18",

[celorodovalho]

I have exactly the same issue @andersmateusz
Did you find any solution?

Actually, when I try to normalize/denormalize any of my Entities, the ApiPlatform normalizers are called and this is not my desired intention.
I want to use Symfony default normalizers, without having ApiPlatform interference.

[andersmateusz]

@celorodovalho
If you have entities that are Api platform resources, but you do not want to generate iri during normalization you can disable iri generation by providing context param like that (at least in version v3.1.18 that I am using):

$normalizationContext = ['iri' => false];
$array = $this->serializer->normalize($someObject, context: $normalizationContext),

Otherwise, as workaround mentioned earlier you can construct your own serializer with your own priorities. As an example:

<?php

declare(strict_types=1);

namespace App\Service\Excel;

use App\Serializer\NameConverter\ExcelNameConverter;
use App\Serializer\Normalizer\EmptyArrayNormalizer;
use App\Serializer\Normalizer\ExcelBackedEnumNormalizer;
use App\Serializer\Normalizer\ImportableEnumNormalizer;
use App\Serializer\Normalizer\PersistentCollectionNormalizer;
use App\Serializer\Normalizer\StructureDenormalizer;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\PropertyAccess\PropertyAccessorInterface;
use Symfony\Component\PropertyInfo\PropertyTypeExtractorInterface;
use Symfony\Component\Serializer\Encoder\CsvEncoder;
use Symfony\Component\Serializer\Mapping\ClassDiscriminatorResolverInterface;
use Symfony\Component\Serializer\Mapping\Factory\ClassMetadataFactoryInterface;
use Symfony\Component\Serializer\Normalizer\DateTimeNormalizer;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;
use Symfony\Contracts\Translation\TranslatorInterface;

final readonly class ExcelSerializerFactory
{
    public function __construct(
        private ClassMetadataFactoryInterface $classMetadataFactory,
        private TranslatorInterface $translator,
        private PropertyAccessorInterface $propertyAccessor,
        private PropertyTypeExtractorInterface $propertyTypeExtractor,
        private ClassDiscriminatorResolverInterface $classDiscriminatorResolver,
        private EntityManagerInterface $em,
    ) {
    }

    public function factory(?string $transDomain, ?string $transPrefix): Serializer
    {
        return new Serializer(
            [
                new StructureDenormalizer($this->em),
                new ImportableEnumNormalizer(),
                new ExcelBackedEnumNormalizer($this->translator),
                new DateTimeNormalizer(),
                new PersistentCollectionNormalizer(),
                new EmptyArrayNormalizer(),
                new ObjectNormalizer(
                    $this->classMetadataFactory,
                    new ExcelNameConverter($this->translator, $transDomain, $transPrefix),
                    $this->propertyAccessor,
                    $this->propertyTypeExtractor,
                    $this->classDiscriminatorResolver,
                ),
            ],
            [
                new CsvEncoder([CsvEncoder::KEY_SEPARATOR_KEY => ' | ']),
            ]
        );
    }
}

You can also register your own service with an unique service id and with your own factory method. For further guide refer to this article: https://symfony.com/doc/current/service_container/factories.html. If you want to create a non-static factory you would have to refactor the code provided to retrieve services as shown here: https://symfony.com/doc/current/service_container/factories.html#non-static-factories.
Then if version of your Symfony application is greater or qual to 6.1 you can inject your custom serializer with an example id custom_serializer like that:

use Symfony\Component\DependencyInjection\Attribute\Autowire;
use Symfony\Component\Serializer\SerializerInterface;
class SomeClass {
public function __construct(#[Autowire(service: 'custom_serializer')] private SerializerInterface $mySerializer){}
}

For further guide refer to this article https://symfony.com/blog/new-in-symfony-6-1-service-autowiring-attributes.
Otherwise, you have to inject your custom serializer via services configuration files or by invoking your serializer factory directly.

[celorodovalho]

@andersmateusz thanks for sharing your solution.

In my case, I would like to avoid any Api-Platform serializer in non-Api-Platform operations.
So the way that I found to avoid that was to create a decorator for \ApiPlatform\Serializer\ItemNormalizer and add some conditions to supportsNormalization and supportsDenormalization methods:

...
    public function __construct(
        private readonly ItemNormalizer $inner
    ) {
    }

    public function supportsNormalization(mixed $data, string $format = null, array $context = []): bool
    {
        if (some conditions based on format or context) {
            return false;
        }

        return $this->inner->supportsNormalization($data, $format, $context);
    }

    public function supportsDenormalization(mixed $data, string $type, string $format = null, array $context = []): bool
    {
        if (some conditions based on format or context) {
            return false;
        }

        return $this->inner->supportsDenormalization($data, $type, $context);
    }
...

[andersmateusz]

Indeed, I think you can write a condition if ($context['disable_api_paltform'] ?? false) return false;. It is possible that you have to decorate collection normalizer as well then. Hope I helped :)

[soyuka]

I think that we need to open a bug report, this is really anoying our normalizers should not be used when using Symfony, I think that the problem comes from us not creating our own Serializer instance.