|
|
Post by AMI_archerwen on Feb 16, 2023 5:06:50 GMT
About the spec mentioned "The service shall ignore OData annotations in the request body, such as the resource identifier, type, and ETag properties".  But for example, we assume that "Sessions" property is "ReadOnly". And if we PATCH SessionService with below request. { "Description": "test", "Id": "test", "Name": "test", "Sessions": {
"@odata.id": "test"
}, "Status": { "Health": "test", "State": "test" } } Shall we also ignore? or Do we need to shows the PropertyNotWritable message for "Sessions" property? |
|
|
|
Post by jautor on Feb 16, 2023 6:25:29 GMT
Do we need to shows the PropertyNotWritable message for "Sessions" property? Yes, as that is a read-only property, the `PropertyNotWritable` message is the appropriate response. Note that the first exception in that clause of the specification calls out "writeable reference properties", which always contain an `@odata.id` annotation (which is obviously not ignored as that is the actual reference). Jeff |
|
|
|
Post by AMI_archerwen on May 3, 2023 3:37:09 GMT
Hi, Sorry. One more question. Based on the redfish spec and the comment by mraineri in this discussion.  We still assume that "Sessions" property is "ReadOnly". 1. If I only provide "@odata.id" in a request, I think it should return 400 + NoOperation message.{ "Sessions": {
"@odata.id": "test"
}} } 2. But if we not only provide "@odata.id" in a request, you mean we shall not ignore right?{ "Description": "test", "Id": "test", "Name": "test", "Sessions": {
"@odata.id": "test"
}, "Status": { "Health": "test", "State": "test" } }
I'm still confused, If we ignore the "Sessions.@odata.id" on the item1, Why we shows the error message for "Sessions.@odata.id." on the item2? |
|
|
|
Post by mraineri on May 3, 2023 16:11:19 GMT
The difference here is "PowerControl" object members contain writable properties. In this case here, "Sessions" is simply a link to the session collection, and will not contain additional properties beyond @odata.id. So, a service would never expect "Sessions" to be present in the request in the first place, unlike with "PowerControl" since the nested objects can be written.
|
|
|
|
Post by AMI_archerwen on May 4, 2023 8:58:47 GMT
So actually like the item1, we also shall response PropertyNotWritable message instead of NoOperation.
|
|
|
|
Post by jautor on May 5, 2023 2:57:30 GMT
So actually like the item1, we also shall response PropertyNotWritable message instead of NoOperation. Yes, I agree, and I think we need to clarify that "exception" in the specification because the PropertyNotWritable response makes much more sense for any link/reference property (whether it is defined in schema as read-only or implemented as read-only). Jeff |
|
|
|
Post by AMI_archerwen on May 5, 2023 10:20:13 GMT
Ok, thanks for the info.
|
|
