Post by malbolge on Apr 7, 2023 13:56:48 GMT
Suppose we have a Redfish device that supports PropertyNotWritable annotations. This annotation indicates that a property was given a value in the request body, but the property is a readonly property.
How should a Redfish system decide to annotate responses? The most obvious way is simply - if a property is not writeable, add the annotation.
This makes sense for a PATCH, where the user specfies what they want to change.
The issue is with PUT, which feeds the entire Resource back into the Redfish device. All the generic stuff like Name, Description, @odata.type, @odata.id - most boilerplate fields are RO. This would mean that for a PUT, a Redfish device would respond with a particularly voluminous blob of annotations for each of these RO properties.
Since the schema specifically limits the number of arguments to no more and no less than 1
"NumberOfArgs": 1,
Each RO property must necessarily have their own annotation.
Is this the intended operation of PUTting a Resource with annotations?
How should a Redfish system decide to annotate responses? The most obvious way is simply - if a property is not writeable, add the annotation.
This makes sense for a PATCH, where the user specfies what they want to change.
The issue is with PUT, which feeds the entire Resource back into the Redfish device. All the generic stuff like Name, Description, @odata.type, @odata.id - most boilerplate fields are RO. This would mean that for a PUT, a Redfish device would respond with a particularly voluminous blob of annotations for each of these RO properties.
Since the schema specifically limits the number of arguments to no more and no less than 1
"NumberOfArgs": 1,
Each RO property must necessarily have their own annotation.
Is this the intended operation of PUTting a Resource with annotations?
