El serializador

Hey @greg-b

Thanks for the kind words, glad the course is treating you well :)
Quick clarification: you're right it's a newer-versions thing, but it landed in API Platform 3.0. In API Platform 2, dev used to rebuilt resource/property metadata (the info read from your getters/setters and phpdoc) on every request via an in-memory array cache, so changes showed instantly. Since 3.0 that metadata lives in the persistent cache.system pool even in dev, and it can't reload just the one resource you touched — it's all-or-nothing — so it won't auto-invalidate on a getter change. Your alias is a perfectly good pragmatic fix.

If you'd rather get the instant-update behavior back, point API Platform's metadata pools at the array adapter in dev only:

# config/packages/api_platform.yaml
when@dev:
    framework:
        cache:
            pools:
                api_platform.cache.metadata.property:
                    adapter: cache.adapter.array
                api_platform.cache.metadata.resource:
                    adapter: cache.adapter.array
                api_platform.cache.metadata.resource_collection:
                    adapter: cache.adapter.array
                api_platform.cache.route_name_resolver:
                    adapter: cache.adapter.array

you may want to double-check the pool in case I got one wrong

Cheers!

Hey @TristanoMilano!

Ooooh, upgrading! :)

But when all properties of an embeddable are null, the endpoint returns an empty array.
I expected the embeddable not to be returned at all, or to be an empty object, but an empty array is returned.
Is that really the desired behavior?

I... think so? So if you're fetching /api/invoice/5 and it has an embeddable address property... and every field in that Address object is null, then it does make sense to me that the response WOULD contain an address property (since Invoice.address does contain an Address object)... but then each property inside that "array" would be missing, since each property is null. But, this is just my opinion: it makes sense to me, but this is the first time I've thought about it!

What is the best workaround?

I don't know if this helps you, but you are free to change skip_null_values to false. They changed it to true because that better fits the JSON-LD spec, iirc. So, feel free to change this to false. Though, then address would still be an array/object... with null properties. So I'm not sure if that is better for your or not :p.

Otherwise, the only solution I can think of is some sort of custom normalizer. That normalize, I think, could "support" the Address object (or any other embeddable), check to see if every property is null, and if it is, return null. Else, call the core normalizer system so it can do its normal work. That... doesn't seem unreasonable to me, but custom normalizers can get complex.

Let me know what you end up doing and how it goes!

Cheers!

@Damian same problem for me
It seems that it is due to the new behavior of the PUT method which is now conform to the RFC 9110.
It does create or replace (all the data of ressource) with the new ones. The partial replace have now to be done with the PATCH method.
You can change this behavior in the config file (api_platform.yaml) : change the standard_put to false

 api_platform:
    title: Hello API Platform
    version: 1.0.0
    # Good defaults for REST APIs
    defaults:
        stateless: true
        cache_headers:
            vary: ['Content-Type', 'Authorization', 'Origin']
        extra_properties:
            standard_put: false

Yup! We will talk about this later in the tutorial. But if you're starting with a new project, a recent recipe change included the standard_put: true in config/packages/api_platform.yaml, which is why you see different behavior than I have in the tutorial up to this point.

I'll add a note to help people with this.

Thanks!

Hey @TronZin

That's unexpected. Could you double-check if that method still exists in the Carbon library? You might have got a newer version and they renamed the method. If that's not the case, your IDE may not have indexed the library correctly

Hey Szymon,

I believe you haven't installed the php-intl module in your local environment. If you're on Ubuntu, you can do this sudo apt-get install php-intl

Cheers!

I had installed intl extension but it required to uncomment lines in several places in php/php.ini (I have Windows 10)

I see... well, as far as I know Windows is not very friendly for developing purposes. That's why I use Windows WSL, it's not perfect but it gets the job done :)