Drop the 'field_' prefix by default

+1 It is redundant.

Hm. I often *change* it to something else, but I think having some sort of prefix makes sense.

We have protection against conflicts with base fields, but you never know what will be added in the future. Having a prefix limits the risk of ever running into a conflict when an entity type gets a new base field, either by itself or anotherm module.

I also use it in our install profile to set it to np8_, and then change it on projects to something project-specific, so I can add more np8_* fields later on without risk of conflict. That's still possible, but by not having a default, people might by less likely to think of that?

This will also break *tons* of tests that currently create fields with e.g. fieldUIAddNewField() and then somehow assert or access that field.

Counter-Proposal: Expose it in the UI, with a recommendation to have a prefix but sites that don't want one can remove it, on their own risk.

How will "This would automatically make our REST support better, as there is less Drupalism involved." be achieved by removing the "field_" prefix? based on what standard will this name change make the REST support better?

As @Berdir points, the intent of the prefix is to allow a core / contrib entity type to add new base fields in any minor / major release without fearing it will clash somewhere with someone's configurable fields (and possibly with supporting business logic around $entity->field_foobar in custom code)

Granted, the specific 'field_‘ string litteral was picked at a time when the non-'field_' things in an entity were not fields...
Today that string is less relevant as a differenciator. But the point of having *some* prefix remains.

the intent of the prefix is to allow a core / contrib entity type to add new base fields in any minor / major release without fearing it will clash somewhere with someone's configurable fields

I think that that highlights that this protection is brittle, since it will still clash somewhere with someone's base fields. One could argue that to avoid collisions field IDs should not be human generated. I get that even if it was a good idea to have machine generated field IDs (there are several pretty obvious drawbacks) it's too late for that implementation.

However I think that this highlights how we are acknowledging some level of conflicts. I think that if we drop the prefix we'll only have potential conflicts when core is adding a base field, since field machine names are ensured to be unique when configuring a field.

My question is: is that marginal increase on risk worth keeping the prefix?

Now that we have JSON API Extras and #2846488: Explore abstracting away "Drupalisms", we can close this. Thanks Wim for bringing it up.

I think it's worth considering this again, perhaps in the context of Drupal 9.

When Drupal is used in an API-first context, the distinction between a machine name and a field label gets blurred since the machine name might be exposed to 3rd party developers who are not the developers of the Drupal site itself.

The GraphQL and JSON:API modules both have workarounds for this, but the DX/site builder experience could be improved if the field name that is exposed via their public APIs were configurable in Drupal core (perhaps on the field config page).

Since it wasn't already mentioned explicitly, I'll call it out: Snake case is not at all the idiomatic style in JavaScript or JSON-based APIs. It's almost universally lower camel case.

My question is: is that marginal increase on risk worth keeping the prefix?

An example anecdote where it can break things.
I have a site that was migrated from D6 to D7 and then D8. This resulted in a field on the user account with the field name "homepage".
Anonymous users could no access node pages while logged-in users could.
template_preprocess_username accesses a property $account->homepage, not sure why something to do with comments maybe in the past. The content of $account->homepage is certainly not expected to be a field object.

We'd need to figure out a way to make this BC with an upgrade path. Since it's only the default for new things, it can be done in a minor, but we'd need to make sure we're not breaking existing assumptions.

Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. Thanks!