>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3585354. --> Reported by: [penyaskito](https://www.drupal.org/user/959536) Related to !1112 >>> <h3 id="overview">Overview</h3> <p> To configure a JS component's content-entity-reference dependencies, an editor needs to pick a target entity type and bundle and then choose which of its fields the component should bind to. Two pieces of information are missing from the Canvas HTTP API today:</p> <ol> <li>The fieldable content entity types and bundles available on the site, filtered to those the current user can view.</li> <li>The fields on a given entity type and bundle that can drive a JS component prop, with pre-built expression strings &mdash; including navigation through reference fields.</li> </ol> <p> Existing endpoints under <code>/canvas/api/v0/ui/content_template/suggestions/*</code> are coupled to a specific Component config entity and cannot serve a generic editor configuring content-entity-reference dependencies.</p> <p> This issue unblocks the UI work tracked in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/canvas/issues/3585355" title="Status: Postponed">#3585355: [PP-1] Entity Reference Selection UI</a></span>.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p> Add two read-only endpoints under <code>/canvas/api/v0/ui/entity-reference/*</code>:</p> <ul> <li><code>GET &hellip;/content-entity-types</code> &mdash; fieldable content entity types and their bundles, filtered by per-bundle view access. Bundle-less entity types are surfaced with a single self-named bundle.</li> <li><code>GET &hellip;/fields/{entity_type}/{bundle}</code> &mdash; field descriptors with pre-built expression strings. An optional <code>?parent=[expression]</code> chains the response to a reference path so the UI can lazily expand reference fields without constructing expressions itself.</li> </ul> <p> Per-bundle and per-field view access checks run against an unsaved stub entity so internal fields (e.g. the user <code>pass</code> hash) are not surfaced to editors who can't read them. Every hop in a <code>?parent=</code> reference chain is also access-checked.</p> <p> Per-field-type expression derivation is encapsulated in a new <code>FieldPropExpressionResolver</code> service. Image, file, link, and entity references whose target is a Media bundle with a known source plugin (Image, VideoFile) surface a single object expression &mdash; <code>{src, alt, width, height}</code> for image-shaped data, <code>{src}</code> for file/video, <code>{uri, title}</code> for links &mdash; instead of an expandable reference. The Media-reference object shapes are defined once in <code>MediaSourceObjectProps</code> so the forward flow (field &rarr; expression, used here) and the inverse flow (component prop schema &rarr; field, used by shape matching) produce identical bindings for the same logical concept. All other entity references stay expandable through <code>?parent=</code>. </p> <p>Both endpoints are documented in <code>openapi.yml</code> and validated at runtime by <code>ApiResponseValidator</code>.</p> <h3 id="user-interface-changes">User interface changes</h3> <p> None in this issue. The editor UI consuming these endpoints is tracked in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/canvas/issues/3585355" title="Status: Postponed">#3585355: [PP-1] Entity Reference Selection UI</a></span>.</p> <h3 id="api-changes">API changes</h3> <ul> <li>Added: <code>GET /canvas/api/v0/ui/entity-reference/content-entity-types</code></li> <li>Added: <code>GET /canvas/api/v0/ui/entity-reference/fields/{entity_type}/{bundle}</code></li> </ul> <h3 id="data-model-changes">Data model changes</h3> <p> None.</p> > Related issue: [Issue #3585355](https://www.drupal.org/node/3585355) > Related issue: [Issue #3573831](https://www.drupal.org/node/3573831)