Management API: Add bulk fetch endpoints for Document Types, Media Types, Member Types, and Data Types

[AndyButland]

Description

On the first load - after sign-in, following a direct link, or a refresh - of a document there are often several requests for document and data types. This particular the case where block editors are used.

As a potential performance improvement, we could look to load all the necessary types in a one request per type, rather than one request per item.

This PR adds additional endpoints to the management API to retrieve full entity details for document, media, member and data types that are identified by a provided collection of IDs.

Change Details

• Adds GET /umbraco/management/api/v1/{entity-type}/fetch?id=guid1&id=guid2 endpoints to retrieve multiple full entity definitions by ID in a single request
• Returns the same response structure as single-item GET endpoints, wrapped in a FetchResponseModel<T> with Total count and Items collection
• Adds shared OrderByRequestedIds<TEntity>() helper method to ManagementApiControllerBase for consistent ordering, ensuring that found items are returned in the same order as requested.

New Endpoints

Entity	Route	Response Model
Document Type	GET /document-type/fetch?id=guid1&id=guid2	FetchResponseModel<DocumentTypeResponseModel>
Media Type	GET /media-type/fetch?id=guid1&id=guid2	FetchResponseModel<MediaTypeResponseModel>
Member Type	GET /member-type/fetch?id=guid1&id=guid2	FetchResponseModel<MemberTypeResponseModel>
Data Type	GET /data-type/fetch?id=guid1&id=guid2	FetchResponseModel<DataTypeResponseModel>

Design Decisions

Why GET instead of POST?

We considered both approaches:

POST (request body)

• Pros: Avoids URL/query string length limits when fetching many entities
• Cons: Semantically incorrect for a read operation; less cacheable; doesn't align with existing patterns

GET (query parameters)

• Pros: Semantically correct for read operations; aligns with existing bulk item endpoints (e.g., GET /item/document-type?id=x&id=y); cacheable
• Cons: URL length limits could be hit with very large ID collections

After some discussion, we chose GET because:

1. It's semantically correct for a read operation
2. It aligns with existing lightweight item endpoints that use the same ?id= query parameter pattern
3. In practice, the number of IDs requested will be manageable within URL limits; and if not, we have client-side patterns for breaking it up into multiple requests.

Why the /fetch suffix?

The /fetch suffix is used to:

1. Reserve the base path for future use: GET /document-type (without suffix) could be used for a future paged list endpoint (e.g., GET /document-type?skip=0&take=100)
2. Distinguish from single-item routes: Avoids any ambiguity with GET /document-type/{id}
3. Explicit intent: Makes it clear this endpoint retrieves specific items by ID

Request/Response Format

Request:

GET /umbraco/management/api/v1/document-type/fetch?id=guid-1&id=guid-2

Response:

{
  "total": 2,
  "items": [
    { /* full entity response model */ },
    { /* full entity response model */ }
  ]
}

Behavior

• Returns entities in the same order as requested IDs.
• Duplicate IDs are deduplicated (first occurrence preserved).
• Empty ID collection returns empty result (not all entities).
• Missing entities are silently omitted (client can compare total to requested count to determine if this is the case if necesssary)
• Authorization inherited from existing base controllers

Testing

I've run through the following using the Swagger UI interface.

• Verify GET /document-type/fetch?id=... returns correct document types
• Verify GET /media-type/fetch?id=... returns correct media types
• Verify GET /member-type/fetch?id=... returns correct member types
• Verify GET /data-type/fetch?id=... returns correct data types
• Verify empty request returns empty response (not all entities)
• Verify duplicate IDs are deduplicated
• Verify response order matches request order

Following existing patterns for management API endpoints, integration tests have been added only to verify authorization is enforced per entity type.

[Copilot]

Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.