Haven't looked at the code, just thinking about the idea...

On one hand this seems like a positive change in that it allows those ids to be documented as part of the farmOS reference implementation (of the farmOS datamodel/api) without weird coupling/artifacts to/of Drupal.

On the other hand, I wonder if we should/can avoid and discourage use of those ids in favor of the UUIDs for programmatic usage and some sort of more meaningful reference (like the 1.x permalinks I guess) value for human usage?

Put another way, there's two questions;

• What scenarios today require the internal id - and why can't we use the UUID for those?
• Which scenarios do we choose to use the internal id because it's shorter (or consistent from test-run to test-run) - i.e. in URL generation?

I pushed a4.x-drupal-internal-wip branch to my fork that shows where I got stuck attempting to changedrupal_internal__target_id:b8d06c4

There are two@todos in the commit that point to potential blockers. I worked around one infarm_api.services.yml by hacking core temporarily to prevent the fatal exception it throws, but the main one is that we can't initialize anew Relationship() outside ofRelationship::createFromEntityReferenceField().

@symbioquine Good questions...

What scenarios today require the internal id - and why can't we use the UUID for those?

Thedrupal_internal__revision_id is an example that doesn't have an equivalent UUID. Entities only have 1 UUID, but they technically have two internal IDs - one for the auto-incrementing serial integer ID in the entity's base database table, and one for the entity's "revision ID".

If a third-party application wanted to leverage data stored in revisions it would need to use this internal ID, I believe.

Which scenarios do we choose to use the internal id because it's shorter (or consistent from test-run to test-run) - i.e. in URL generation?

I'm not sure if I understand this question, but I can think of one case were internal IDs are better to use than UUIDs. Configuration entities (eg: a user's role) have non-numeric internal IDs (likefarm_manager) but also have auto-generated UUIDs.

These two Drupal core issues explain why thedrupal_internal__target_id meta property was added:

https://www.drupal.org/project/jsonapi/issues/3034701#comment-12981809

https://www.drupal.org/node/3036593

Which scenarios do we choose to use the internal id because it's shorter (or consistent from test-run to test-run) - i.e. in URL generation?

I'm not sure if I understand this question,

The "we" I was referring to is anybody calling the API I guess.

I wasn't so much thinking of the revisions case withdrupal_internal__revision_id as thedrupal_internal__(target)?_id cases...

but I can think of one case were internal IDs are better to use than UUIDs. Configuration entities (eg: a user's role) have non-numeric internal IDs (likefarm_manager) but also have auto-generated UUIDs.

Another example is anybody generating QR codes will tend to prefer the shorter numeric values for generating URLs since those will be shorter and thus result in smaller easier to scan QR codes.

Similarly, anywhere somebody might need to type in a URL or hand-validate one, the numeric code will be more user-friendly. (Hopefully this is rare)

Another example is tests which insert/modify data and then access it via the API are probably more readable with the numeric ids vs the UUIDs. Although in this case having the "drupal_internal" prefix isn't terrible, it suggests that we shouldn't be marking these ids as neither "internal" or "Drupal specific" if that's what we're actually testing against.

Summing that up;

• Should these numeric ids be more "first class" identifiers - i.e. not even marked as "internal" given that they have valid use-cases in "external" applications?
• Alternatively, should we provide a better "short identifier" instead and actually more strongly discourage the use of the "drupal_internal_*" identifiers?

Makes sense - these are all great questions - perhaps worthy of a broader forum discussion on the topic. I worry about them getting lost in this PR, which only pertains to the JSON:API aliases given to the internal IDs, currently:drupal_internal__*, and after this PR simplyinternal__*.

I forgot to highlight this in my original description, but the reason I'm proposing this small change right now is because it would technically be a "breaking change" so it's something worth considering for 4.x in the very near term.

My two cents here... I think the current internal IDs are fine. They are helpful in case an external user wants to use them to query the API via a URL or similar... generally however I agree that they are inferior most of the time compared to the actual UUIDs which should always be present. In general, IMO I would keep them.

Re. removing thedrupal_ I think it makes sense. I can't think of reasonable cases in which that is necessary... I suppose it tells someone who's receiving the information 2nd hand that it came originally from a drupal database... but I don't know why that would matter or if/how that wouldn't be generally accessible through other means (like theself links which usually indicate that it's a farmOS instance).

@paul121 suggested a clever workaround on the dev call today...

In Drupal 11.2 (#980) JSON:API now supports adding metadata programmatically (https://www.drupal.org/node/3280569).

I mentioned this above, but it seemed like a dead end because it only allowsadding metadata, notmodifying the one we want to change.

@paul121's idea was to simplyadd an additionalinternal__target_id alongside the existingdrupal_internal__target_id. This way, we provide consistency with the presence ofinternal__* attributes like this, and we just consider the old one a vestigial appendage that can be ignored (perhaps until Drupal core facilitates removing/changing it directly).

That feels like a good next step here. It means that this will depend on#980, though, so let's get that merged first.

In Drupal 11.2 (#980) JSON:API now supports adding metadata programmatically (https://www.drupal.org/node/3280569).

I tested this, but it does not do what we want.

I can add meta key/values todata.0.relationships.uid.meta, but not todata.0.relationships.uid.data.meta, which is wheredrupal_internal__target_id is.

I think the only other option to achieve this would be to patch Drupal core. And if we went that route we might as well patch both instances ofdrupal_internal__*.

I'm not sure this is important enough to justify maintaining another core patch.

I'm going to mark this as "postponed" on the hope that others in the Drupal core community come up with a better way to do this, but it's not something I'm going to invest more time in right now...