It looks like these lines are the only difference here from __experimentalSaveSpecifiedEntityEdits.

Is there a reason that __experimentalSaveSpecifiedEntityEdits doesn't use the existing entity as a base? If not, perhaps that function could be updated rather than creating a new, mostly duplication function?

cc @getdave @ntsekouras who had PRs that used __experimentalSaveSpecifiedEntityEdits somewhat recently.

I thought about that, too, I decided to create a new one to be explicit about the difference with __experimentalSaveSpecifiedEntityEdits and avoid changing the existing functionality that used by other parts of the codebase too.

Still, if we find that the behavior of __experimentalUpdateSpecifiedEntityEdits is the originally intended behavior of __experimentalSaveSpecifiedEntityEdits, we can add the changes from this PR to __experimentalSaveSpecifiedEntityEdits instead of creating the new function.

Just noting that we shouldn't be adding new experimental APIs anymore, we should add private APIs instead.

Also it's not really clear what this API offers in addition to what saveEntityRecord does?

saveEntityRecord saves all the changes to the database. __experimentalUpdateSpecifiedEntityEdits saves only the specified edits.

Let's take this case as example:

• Database has this content:

{ "a": "a"}

• Client-side entity has:

{ "a": "a", "b":"b", "c":"c" }

• We want to persist to the database only the following JSON without changing the client side entity:

{ "a": "a", "c":"c" }

Using saveEntityRecord

saveEntityRecord( 'root', 'post-type', 1, { "a": "a", "b":"b", "c":"c" } )

{ "a": "a", "b":"b", "c":"c" } is persisted to the database.

Using __experimentalUpdateSpecifiedEntityEdits:

__experimentalUpdateSpecifiedEntityEdits( 'root', 'post-type', 1, [  'c'  ] );

{ "a": "a", "c":"c" } is to the database.

Using __experimentalSaveSpecifiedEntityEdits:

__experimentalSaveSpecifiedEntityEdits( 'root', 'post-type', 1, [  'c'  ] );

{"c":"c" } is to the database without changing the client-side entity.

I added these examples to the PR's description.

Probably the behavior added in this PR for __experimentalUpdateSpecifiedEntityEdits was the one originally thought for __experimentalSaveSpecifiedEntityEdits. In that case, we can move the additions to that function instead of adding a new one.

__experimentalUpdateSpecifiedEntityEdits( 'root', 'post-type', 1, [ 'c' ] );

But in this case, can't we just send saveEntityRecord( 'root', 'post-type', 1, { "c":"c" } ) directly? In other words, can't we retrieve the edits that we want to save and just pass them (or not even mark them as edits). I'm pretty sure we do this already in other places already.

__experimentalSaveSpecifiedEntityEdits to be honest I don't know much about this function, I need to check the history.

This would create a new post revision only with { "c":"c" } content in the database instead of the desired { "a": "a", "c":"c" }.

I guess that it's possible that it's an endpoint issue then because if I'm not wrong all of the endpoints in Core work as "PATCH" (maybe not the global styles one, we need to check)

It is also why we didn't see the issue before with __experimentalSaveSpecifiedEntityEdits (we never used it with the global styles endpoint before)

Oh so you're actually trying to send only settings.typography.fontFamilies and not settings. That is going to override the whole "settings" object of course. So IMO, you should just send the update settings object entirely.

The endpoints don't do "nested patches", only top level.

This would create a new post revision only with { "c":"c" } content in the database instead of the desired { "a": "a", "c":"c" }.

I don't think this is true for top level keys.

This would create a new post revision only with { "c":"c" } content in the database instead of the desired { "a": "a", "c":"c" }.

I don't think this is true for top level keys.

That's correct in my testing for the global-styles endpoint, and true generally across the REST API. styles are preserved here when a font is activated because it's a different top level key, but settings are reset (without this PR) because they're empty except for settings.typography.fontFamilies.