Post by joergweed on Feb 23, 2018 19:02:49 GMT
Hello,
this question is somewhat related to redfishforum.com/thread/104/patch-unsupported-properties, although different enough to start another thread.
The wording of spec sections about PATCH seems ambiguous about this case:
How to treat partial success on a PATCH containing multiple properties of a resource, all being valid according to schema, and present in the given implementation (i.e. they appear when you do a GET to the same resource).
The spec states how to handle read-only properties in [6.4.4.3. Update]. I read this: if *some* of the properties cannot be modified because they are read-only, but others *were* updated, then return 200 and state which properties could not be updated in the ExtendedInfo. Correct?
How to deal with a case where *some* of the properties were not updated because of other reasons: value was out-of-range for this implementation, or some other internal reason that the update couldn't succeed. Other properties in the same PATCH, however, could be updated. Should the same apply in that case as above: return 200, and state which properties were NOT updated and why, in the ExtendedInfo?
How about the case were *all* properties were eg. out of range and therefore not updated? return 200 and list all properties in ExtendedInfo, or return 405?
In another section of the spec it states this: "The implementation may reject
the update operation on certain fields based on its own policies and in this case, not process any of the
requested modifications." It is not clear if "out-of-range" of a value should indeed lead to rejecting the entire PATCH if it contains only *some* properties that could be updated OK. It would be very hard for any implementation to safely roll back a transaction of multiple property updates in case a partial update was started while one property was detected out-of-range during the operation. Sometimes these things cannot be completely excluded via pre-checks before a transaction is started. Multiple properties of a complex resource like Systems/1 can be very unrelated to each other. It would be very desired if the spec could clarify this in a way that if a PATCH contains valid properties (existing in this resource) then a partial success is acceptable. The client would check ExtendedInfo or do another GET to check which properties updated and which didn't.
What's your recommendation?
Thanks!
this question is somewhat related to redfishforum.com/thread/104/patch-unsupported-properties, although different enough to start another thread.
The wording of spec sections about PATCH seems ambiguous about this case:
How to treat partial success on a PATCH containing multiple properties of a resource, all being valid according to schema, and present in the given implementation (i.e. they appear when you do a GET to the same resource).
The spec states how to handle read-only properties in [6.4.4.3. Update]. I read this: if *some* of the properties cannot be modified because they are read-only, but others *were* updated, then return 200 and state which properties could not be updated in the ExtendedInfo. Correct?
How to deal with a case where *some* of the properties were not updated because of other reasons: value was out-of-range for this implementation, or some other internal reason that the update couldn't succeed. Other properties in the same PATCH, however, could be updated. Should the same apply in that case as above: return 200, and state which properties were NOT updated and why, in the ExtendedInfo?
How about the case were *all* properties were eg. out of range and therefore not updated? return 200 and list all properties in ExtendedInfo, or return 405?
In another section of the spec it states this: "The implementation may reject
the update operation on certain fields based on its own policies and in this case, not process any of the
requested modifications." It is not clear if "out-of-range" of a value should indeed lead to rejecting the entire PATCH if it contains only *some* properties that could be updated OK. It would be very hard for any implementation to safely roll back a transaction of multiple property updates in case a partial update was started while one property was detected out-of-range during the operation. Sometimes these things cannot be completely excluded via pre-checks before a transaction is started. Multiple properties of a complex resource like Systems/1 can be very unrelated to each other. It would be very desired if the spec could clarify this in a way that if a PATCH contains valid properties (existing in this resource) then a partial success is acceptable. The client would check ExtendedInfo or do another GET to check which properties updated and which didn't.
What's your recommendation?
Thanks!
