I try to create a custom API with custom endpoints where API users can receive entity data from our page. We want to have flat arrays for most of the fields and some additional custom data added so I tried to implement some custom normalizer classes. I found out that supportsNormalization() is the place where the decision is made if my normalizer is used, but I have no context. I just have the object which needs normalization and the format on which I can say Yes, please use my normalizer. As I don't want to force all my entities everywhere in the project be normalized with flat array this is too restrictive for us. I want to use my normalizer only when the entities should be normalized for delivering it in a specific API. Is there a way to achieve this?


The supportsNormalization method comes from the Symfony Serializer component, and for this reason it is up to the implementation to decide what to do with these items.

However Drupal core serialization module provides a nice base class, ComplexDataNormalizer, which is probably the class your Normalizer should extend when you need to normalize a complex data type such as an Entity, Map or a list of those things.

Classes that extend the base class should provide a unique interface to target: ComplexDataNormalizer::$supportedInterfaceOrClass.

With the Symfony service locator, as long as the normalizer weight is adjusted for any conflicts, then it will be used. A good example of this is to look at the core hal module.

So for instance, in my module xero, I provide my own Typed Data data types to interact with a third party API and the top-level data types I have my own interface.


class XeroNormalizer extends ComplexDataNormalizer implements DenormalizerInterface {

  protected $supportedInterfaceOrClass = 'Drupal\xero\TypedData\XeroTypeInterface';

You can read more about how the Drupal serialization module works in the documentation: https://www.drupal.org/docs/8/api/serialization-api/how-the-serializer-works

  • Thank you for your detailled response though I fear that this is not an answer to my question. ComplexDataNormalizer just extends NormalizerBase which itself uses the above mentioned supportsNormalization() method (what I already used). Your core idea is to implement a custom TypedData. It is the same what I described: the normalizer is suitable for a specific type of object (your custom TypedData) not for a specific path, usage, context. – Tobias Krause Aug 14 at 5:30
  • Normalizers are services so you could inject Drupal services into your class and do path checking? – mradcliffe Aug 14 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.