Version 2.4.3 has changed the normalization process

[gnumoksha]

Scenario

I'm returning an instance of https://github.com/myclabs/php-enum (which implements JsonSerializable) as one of the properties of a resource.

Expected behaviour

Only the serialization fields will be returned in the response. Eg.:

"fooField": {
    "id": 40,
    "name": "Foo",
    "displayName": "Bar"
  },

Actual behaviour

As of version 2.4.3, this is returned:

"fooField": {
    "@context": "/api/contexts/Customers",
    "@id": "/api/customers",
    "@type": "hydra:Collection",
    "hydra:member": [
      40,
      "Foo",
      "Bar"
    ],
    "hydra:totalItems": 3
  },

Also, looking at the changelog it seems to me that version 2.4.3 is not a bug fix.

[gbustin]

Same issue here, with simple arrays being converted to hydraCollections.

[teohhanhui]

If you implement JsonSerializable, you're handling the serialization of that class. The behaviour is correct. It's not a bug.

Sorry, it should still not be turned into a collection. You're right. That's a bug.

[teohhanhui]

This is really tricky. On hindsight, we should have required the collection to be wrapped.

[teohhanhui]

One idea I had was to delegate to the ItemNormalizer from within the CollectionNormalizer, when we detect that $context['collection_operation_name'] is not set. But it means we'd be bypassing the serializer, so that's a no go as custom normalizers would not be used.

I'm out of ideas as of now.

[teohhanhui]

Could we perhaps lower the priority of the CollectionNormalizer?

But we should really think about introducing a CollectionInterface and deprecate using raw values.

[gnumoksha]

@teohhanhui as an outsider I think only the resource itself should be normalized by default or at least only objects or arrays that came from a data transformer.

Looking at the result of serialization it is making the wrong assumption that "fooField" is a "Customer" which does not make sense.

Personally, I like the simplicity of the fractal, which is more explicit and straight to the point. Perhaps its design can be of any help.

By the way, I would really appreciate if API Platform doesn't do this kind of changing in a minor version.

[teohhanhui]

Looking at the result of serialization it is making the wrong assumption that "fooField" is a "Customer" which does not make sense.

No, that's not what's happening. It's because we have no way to tell in the collection normalizer whether we're dealing with a real collection or an item that happens to be iterable:

core/src/Serializer/AbstractCollectionNormalizer.php

Line 56 in e0eba21

return static::FORMAT === $format && is_iterable($data);

I think lowering the priority of the collection normalizer should fix the problem. Can you try it? (And feel free to submit a PR if it works.)

By the way, I would really appreciate if API Platform doesn't do this kind of changing in a minor version.

I think you meant patch versions, as it's normal to introduce new features in minor versions. Anyway, it was because we had bugs to fix. See #2592 and #2679

[teohhanhui]

Sorry, I was mistaken. It's because our ItemNormalizer has a lower priority than Symfony's JsonSerializableNormalizer. Let me check if adjusting the priorities fixes the problem...

[teohhanhui]

This is actually the same as api-platform/api-platform#1018

[teohhanhui]

Should be fixed by #2921 which will be in 2.5.