Problem/Motivation
To provide a serialization of an entity, the serialization module will have to add a new route for the entity. This route should have the same URI template as the original route, but a different format and possibly a different _method.
This route will map to a controller in the serialization module. This controller will have to load the entity.
The two pieces of information that the controller would need to perform an entity_load are the entity type and the entity id. The entity type should be possible to add as an argument to the route at the time of route definition. However, the position of the entity id placeholder in the URI template is not available to the serialization module.
While one possibility might be to just include the full route string in the URI callback, that would contain the entity-specific variable name for the ID, such as 'nid'. Because Symfony's wildcard placeholder matches on variable name, there would have to be a different controller for each variable name (i.e. one for nid, one for cid, etc).
Proposed resolution
There are a couple of possible solutions:
- Provide an 'entity_id argument' for the path, similar to the 'bundle argument' that is provided in the admin array.
- Use a route such as entity/{entity_type}/{eid} as the canonical URI for all entities. Then, alias (node|user|comment)/{id} to that route.
Comments
Comment #1
Anonymous (not verified) commentedComment #2
Anonymous (not verified) commentedCrell says that option #1 might not work based on #1801570: DX: Replace hook_route_info() with YAML files and RouteBuildEvent.
Comment #3
moshe weitzman commentedPerhaps a good approach is #1783964: Allow entity types to provide menu items
Comment #4
Anonymous (not verified) commentedI believe that option 1 would still be a solution even if the route definition moves to CMI. We won't be able to change routes dynamically at run time, but from what others have said I believe it would be possible to create them dynamically at config build time.
Comment #5
Anonymous (not verified) commentedCrell just commented in #1783964 and proposed using a standard. If that gets accepted there, then this issue could be resolved.
Comment #6
effulgentsia commentedI'm confident we'll find some solution here. Until we do, is this hindering progress on JSON-LD and web services? In any case, this relates to web services, so tagging accordingly.
Comment #7
Crell commentedI don't think this is a hard blocker for JSON-LD integration. It's more a nice-to-have, really. Worst case, modules that want to expose an entity type as JSON-LD manually add a route.
Comment #8
Anonymous (not verified) commentedAfter posting this, I looked at another way to do it where a serialization module doesn't have to concern itself with routes. I hope to discuss it in today's WSCCI meeting.
I think it's preferable to keep the route logic outside of JSON-LD to preserve modularity. For example, JSON-LD module shouldn't have to know that it needs to run entity_load, or that on 'node' routes it will be handling a group of entities, but on 'node/1' it will handle just one. Instead, it would be great if JSON-LD just had to know how to go from an entity to it's serialization and back.
Comment #9
Anonymous (not verified) commentedThe core problem this issue addresses will be taken care of as part of the REST module, which has started here #1816354: Add a REST module, starting with DELETE