Migration path for PUT with nested objects

[Tib-z]

My application always sends the whole nested object structure to the api platform (2.7) to persist changes. Currently uses PUT that works just fine.
Upgrading and enabling standard_put will break this and not clear what is the recommended migration path.
Using PATCH there's no option to send nested/embedded collections.
Using PUT I would have to send all properties, however not all of them are exposed so those properties would be lost.
Doing partial updates on certain resources is not really an option as it would require to change the frontend and backend services.

There are several issues about this topic, still not sure what is the preferred way.

[soyuka]

Hello Carobit,

Using PATCH there's no option to send nested/embedded collections.

Yes but only because we implemented the Merge-Patch format. There are other PATCH formats that one can implement to handle things differently. We're open to discussion to implement other standards, or one could build it in a library.

Using PUT I would have to send all properties, however not all of them are exposed so those properties would be lost.

If a property is not exposed on your API, why would API Platform remove it (eg: set to null)? We need to check this but I don't think that it's the case.

Using embedded resources on write is not great implementation-wise and induces lots of complexity. We suggest to follow the Edge Side API recommendation.
Let's say you have books and authors and you currently update authors via books, instead you should update the author, then use IRIs to update the book if needed.

We introduced uriTemplate on the ApiProperty attribute so that you could get an IRI instead of your collection :

core/docs/guides/return-the-iri-of-your-resources-relations.php

Lines 194 to 199 in e65d2c3

	"@context" => "/contexts/Brand",
	"@id" => "/brands/1",
	"@type" => "Brand",
	"name"=> "Ford",
	"cars" => "/brands/1/cars",
	"headQuarters" => "/brands/1/addresses/1"

Then if you need to update the collection you do this by removing/adding items on that resource instead.

If you don't want to break your API you can always create a custom Symfony Normalizer that will support the old PUT behavior.

Last but not least, we do recommend splitting Doctrine Entities from your API Resources, for example to not expose some fields.