Context: We are developing a library to read JSON:API Schema data from Drupal so that it can be used by a JavaScript library to understand the available entity types and bundles available. Specifically this is for farmOS.js - which will connect to a farmOS site, which may have any combination of modules installed that provide different bundles for different purposes. So we're using JSON:API Schema to make farmOS.js able to determine these things automatically. :-)
Questions:
- Why isn't entity
id described alongside type, attributes, and relationships? (see first example code below)
- Why are
drupal_internal__id, drupal_internal__revision_id, and revision_translation_affected includes under the required attributes? They should not be required to POST. (see second example snippet below)
Example 1 (no id):
{
"$schema": "https://json-schema.org/draft/2019-09/hyper-schema",
"$id": "http://localhost/api/log/activity/resource/schema",
"title": "Activity log",
"allOf": [
{
"type": "object",
"properties": {
"type": {
"$ref": "#definitions/type"
},
"attributes": {
"$ref": "#/definitions/attributes"
},
"relationships": {
"$ref": "#/definitions/relationships"
}
}
},
{
"$ref": "https://jsonapi.org/schema#/definitions/resource"
}
]
}
Example 2 (required attributes):
{
"required": [
"drupal_internal__id",
"drupal_internal__revision_id",
"revision_translation_affected"
]
}
Comments
Comment #2
bradjones1Because the id will be covered by the reference to the json-api schema for resources, as referenced in the second allOf requirement. The type is called out specifically because it's set to be a const matching the resource name.
Agreed... I believe this is because of them being marked read-only; see #3257329: Computed/read-only fields should not be marked required
Closing as a duplicate since the second question addresses a bug separately ticketed.