Post by nanzhou on Jan 27, 2022 23:55:48 GMT
Hello everyone, I have a question on Query Parameters.
Is it valid for a Redfish Service to implement Query Parameters (e.g. $expand) for only a set of Resources, but not all Resources?
I did find in the Spec, a service should return 400 Bad Request status code with the QueryNotSupportedOnResource message for any implemented query parameters that are not supported on a resource in the request.
The intuition is that on OpenBMC community, each resource has different aggregation logics. For example, for $expand on sensor collections, there are efficient ways to query all properties of sensors of a chassis in a single round trip of DBus transactions, which saves a lot time; but for other resources, we might not have an efficient way to implement $expand.
I understand that we can implement a very naive way of handling $expand: before sending back a GET response, we just hold it on and walk through all the members (use sth like a querying queue), and return back the aggregation result. But this only saves HTTP round trips, which doesn't help a lot.
What's the official answer to this? Can a service say it supports $expand in ProtocolFeaturesSupported but only implements $expand in a certain set of resources, and return QueryNotSupportedOnResource otherwise?
Look forward to your reply!
Is it valid for a Redfish Service to implement Query Parameters (e.g. $expand) for only a set of Resources, but not all Resources?
I did find in the Spec, a service should return 400 Bad Request status code with the QueryNotSupportedOnResource message for any implemented query parameters that are not supported on a resource in the request.
The intuition is that on OpenBMC community, each resource has different aggregation logics. For example, for $expand on sensor collections, there are efficient ways to query all properties of sensors of a chassis in a single round trip of DBus transactions, which saves a lot time; but for other resources, we might not have an efficient way to implement $expand.
I understand that we can implement a very naive way of handling $expand: before sending back a GET response, we just hold it on and walk through all the members (use sth like a querying queue), and return back the aggregation result. But this only saves HTTP round trips, which doesn't help a lot.
What's the official answer to this? Can a service say it supports $expand in ProtocolFeaturesSupported but only implements $expand in a certain set of resources, and return QueryNotSupportedOnResource otherwise?
Look forward to your reply!
