Support ability to fetch all resources currently available from Drupal
mattgrill opened this issue · comments
Currently Hydrant only supports the resources that have been specifically added, however #2 should fix some of that. In the current Drupal REST implementation there is no way to discover what resources are available.
A discovery resource could be consumed which describes what resources are available and provide additional metadata about each entity.
GET /entity/types
{
'node': {
'label': 'Content',
'type' : 'content',
'more': '/entity/types/node'
},
'node_type': {
'label': 'Content type',
'type' : 'config',
'more': '/entity/types/node_type'
},
…
}GET /entity/types/node
{
'label': 'Content',
'type' : 'content',
'methods': {
'get': '/node/{node}',
'post': '/entity/node'
},
'fields': {
'title': {
'cardinality': 1,
'type': 'string',
'required': true,
…
}
}
}While this is currently not possible, a stub implementation could be created.
We discussed this. I think you can provide a matching hydrant module for Drupal itself, to fill the gaps until Drupal core itself has determined how to expose this metadata.
@mattgrill /entity/types/node could be tricky. Would you expect to return back all fields that are on all content types(bundles)? Then specify which bundles each field is available on?
Also some metadata about the fields like required would be different on different bundles.
@tedbow I'm not attached to the /entity/types/node pattern, just a thought. I think the expectation would be to return information about all the fields that are on the content type.
Note that once https://www.drupal.org/node/2724823 lands, we'll only need to add FieldStorageConfigAccessControlHandler and then hydrant would be able to read those config entities … albeit with one REST request per field … and assuming it's going to be world-readable.
… but at least it'd make some of this possible :)
@wimleers Thats excellent. We can potentially tolerate a single request per field abstraction initially. We could even cover this behavior up internally and provide a single interface to users.
@mattgrill
I have started on the Drupal module that will provide this type of information
https://github.com/tedbow/hydrant
Currently it has 1 permission on the Drupal side and these 2 resources.
GET /entity/types/node
Currently only returns base fields
@tedbow Putting our example JSON from our talk yesterday here for reference.
{
"node": {
"label": "Content",
"type": "content",
"methods": {
"GET": "/node/{node}",
"POST": "/entity/node",
"DELETE": "/node/{node}",
"PATCH": "/node/{node}"
},
"more": "/entity/types/node/{bundle}",
"bundles": ["page", "basic"]
}
}@mattgrill ok all of this should be in https://www.drupal.org/project/waterwheel
One thing I was thinking of though. Does it make sense to return back all entity types as it doing now or just the entity types that are REST enabled("methods" is not empty)?
Also if we decide to return back just REST enabled entity types should the module enable common entity types on install?
@tedbow I think it would make sense to return just the entities that are REST enabled. Is is possible to rest-enable entities over some resource that the Waterwheel module would provide?
I think we have addressed some of this in #6.