The basic idea is simple enough: it would be nice to distinguish Drupal-specific data that's sent over JSON:API, such as drupal_internal__id and revision_user, by placing it in the meta information. Currently that data is going into the attributes and relationships fields, which is a little problematic. That's b/c on the client we then need to manually separate that data out so it's clear its server data, which shouldn't be edited client-side and probably shouldn't be displayed to the user. It also just seems more intuitive, b/c this isn't primary data related to the farm itself, so much as metadata about how it's been stored and accessed. JSON:API provides the meta field for this purpose, so it makes sense to use it. I suppose for fields like revision_user it could debated that it could go under relationship, but I think just because it could doesn't mean it can't go under meta.
Beyond mere ergonomics, I think this could be a crucial distinction in the future for how we describe and document entities in the data model. In essence, it would mean we could safely say that attributes and relationships are only for base fields and bundle fields, and that everything else should be placed in meta. We could then go on to have more strict definitions of what fields belong to specific entity types. We may even want to impose a rule that if modules wish to add fields to a bundle, that they can only do so as metadata (maybe). This would go a long ways towards enabling us to version entity types, as we've discussed elsewhere. And versioning, I believe, will be key to implementing conventions and other features in the pipeline.
Note that this isn't a pressing concern for the upcoming 2.0.0-beta release, but I think it's an important consideration as we move forward with the data model.
n/a
This may need to be an upstream change to core, if I understand correctly. I'll open a separate, more general issue there that references this one, to see if there are any major objections, before figuring out how to proceed. I'll defer to @m.stenta at that point as to what exactly needs to be done.
Here are the fields I've marked so far as metadata in farmOS.js:
- drupal_internal__id
- drupal_internal__revision_id
- langcode
- revision_created
- revision_log_message
- default_langcode
- revision_translation_affected
- revision_default
I don't guess we want to include fields like created, but we should probably consider where we draw the line with data like that.
Yes?
Closed: outdated
2.0
API
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.