A civic dashboard only needs each Intersight server’s Name and Serial. Which query option keeps the payload small?
Select an answer to reveal the explanation.
Short Explanation
If you only need name and serial, ask for those columns—$select is like ordering two items off a menu instead of the whole kitchen.
Full Explanation
A civic dashboard that only needs each Intersight server’s Name and Serial should project those fields with $select=Name,Serial on the constructed GET. Projection returns only the properties the application will render, which cuts payload size and parse time when the city inventory spans hundreds or thousands of claimed compute objects.
Omitting query options so every property returns by default works functionally but fails the “keep the payload small” requirement: large default documents burn bandwidth and client CPU for fields the dashboard never shows. Using $expand on related objects instead of projecting fields fails by concept—expand widens the graph of related MOs; it does not shrink the primary object’s property set. Switching to a UCS Manager configResolveClass call fails because that is a different platform’s XML retrieve and is not the Intersight SaaS projection option asked for here.
Exam caveat: $select and $filter often combine on the same request; selecting Name,Serial does not invent filtering—if you still need library-r720 only, keep $filter as well rather than assuming projection alone narrows the set.
Operational check: capture Content-Length or response byte size for an unprojected PhysicalSummaries page versus the same call with $select=Name,Serial, confirm the dashboard still renders identifiers correctly, and keep Serial in the select list so duplicate hostnames in different facilities remain distinguishable.