Summary

The two metaverse-object read endpoints return the same conceptual data in inconsistently-named/shaped properties. Review both responses and decide a normalisation strategy (strategy itself is TBD).

Background

Get-JIMMetaverseObject (and the REST endpoints behind it) return different property names depending on whether you fetch the bulk list or a single object:

What's worth normalising

1. Object type representation (typeId/typeName vs type:{id,name}) — genuine inconsistency. Both carry exactly id + name; there is no data-shape reason for one to be flat and the other nested. It is drift from two independently-authored DTOs (Header flattens the FK per the projection convention; Full maps the Type navigation property). Strong candidate to align (e.g. nest type:{id,name} in the Header DTO too).

2. Attributes (attributes map vs attributeValues typed list) — different on purpose, possibly fine. These are genuinely different shapes: the list view returns a cheap name->string map for grids; the detail view returns richly-typed value objects (stringValue/intValue/boolValue/referenceValueId/contributedBySystemName...). The differing names correctly signal differing shapes. Decide whether to leave as-is (recommended) or unify on a single (possibly truncated) shape.

Constraints / things to weigh

• This is a breaking change to the public REST API contract and to the PowerShell module's output object shape. Needs its own PR, a CHANGELOG entry, and likely PS module + docs updates.
• The Header/Full weight split itself is intentional and matches the documented retrieval taxonomy (src/CLAUDE.md). Normalisation should preserve the light-vs-heavy distinction; only the naming/shape of equivalent fields is in scope.
• Check the other list/detail DTO pairs (e.g. PendingDeletionDto also exposes typeId/typeName) for the same inconsistency so any fix is applied consistently.

Acceptance criteria

• Decision recorded on whether/how to normalise object-type representation across list and single responses
• Decision recorded on attribute representation (leave split vs unify)
• If changing: API + PS module + docs + CHANGELOG updated, with a note on the breaking-change impact

References

• src/JIM.Web/Models/Api/MetaverseObjectHeaderDto.cs
• src/JIM.Web/Models/Api/MetaverseObjectDto.cs
• src/JIM.Web/Controllers/Api/MetaverseController.cs (GetObjectsAsync, GetObjectAsync)