Backend APIs for Entity Reference Selection [#3585354]

Overview

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:

The fieldable content entity types and bundles available on the site, filtered to those the current user can view.
The fields on a given entity type and bundle that can drive a JS component prop, with pre-built expression strings — including navigation through reference fields.

Existing endpoints under /canvas/api/v0/ui/content_template/suggestions/* are coupled to a specific Component config entity and cannot serve a generic editor configuring content-entity-reference dependencies.

This issue unblocks the UI work tracked in #3585355: [PP-1] Entity Reference Selection UI.

Proposed resolution

Add two read-only endpoints under /canvas/api/v0/ui/entity-reference/*:

GET …/content-entity-types — 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.
GET …/fields/{entity_type}/{bundle} — field descriptors with pre-built expression strings. An optional ?parent=[expression] chains the response to a reference path so the UI can lazily expand reference fields without constructing expressions itself.

Per-bundle and per-field view access checks run against an unsaved stub entity so internal fields (e.g. the user pass hash) are not surfaced to editors who can't read them. Every hop in a ?parent= reference chain is also access-checked.

Image, file, link, and entity references whose target is a Media bundle with a known source plugin (Image, VideoFile) surface a single object expression — {src, alt, width, height} for image-shaped data, {src} for file/video, {uri, title} for links — instead of an expandable reference. src chains through the referenced file's uri.url so the editor receives a URL, not a file entity. This mirrors the canonical shapes in ShapeMatchingHooks::getObjectProps(). All other entity references stay expandable through ?parent=.

Both endpoints are documented in openapi.yml and validated at runtime by ApiResponseValidator.

Remaining tasks

Follow-up: collapse the per-field-type object mappings into a typed-data-driven helper shared with EntityFieldPropSourceMatcher. Marked with a @todo in the controller; out of scope for this issue.