|
Post by JenHuang on Jan 14, 2022 10:38:17 GMT
Hi, As the DSP 0266 redfish described, there allow to PATCH empty json object for resource. The empty json object be treated as no changes.
Assume the following case, 1. PATCH https://{redfish}/redfish/v1/Managers/Self/NetworkProtocol
request-body, { "SSH": {}, "VirtualMedia": { "Port": 5566 } }
There is empty json object(SSH) of request body, should redfish server accept this request and treat as no changes or this rule only apply to resource level.
|
|
|
Post by shawn on Jan 14, 2022 10:45:50 GMT
IMO, it shouldn't be acceptable since DSP0266 only said it could PATCH an empty json object for resource not a property of a resource. And I think there's an annotation to indicate which property changed successfully or not. However, I wonder why users will issue this request if they don't want to change it?
|
|
|
Post by mraineri on Jan 14, 2022 15:38:09 GMT
That type of request is perfectly acceptable. It's very similar to the PATCH on array semantics where "{}" is used to indicate "no change at this array index". Essentially a general parser would step into SSH for modifications, iterate over the properties (in this case there is nothing to iterate over), and step outside the object to perform other modifications.
Generally I would not expect clients to make that type of request, but from the perspective of the syntax and behavior of JSON handlers, it would be a no-operation.
|
|
|
Post by mraineri on Jan 14, 2022 20:08:49 GMT
One point to clarify is the request would be perfectly acceptable if the "SSH" property is supported by the service. I can see the service rejecting the request if "SSH" property is simply not supported on that particular resource (or by the service in general).
|
|
|
Post by JenHuang on Jan 17, 2022 3:04:58 GMT
Thank for answer the problem and this very clear to know we don't need to distinguish the different case for resource level and json object level.
|
|
|
Post by AMI_Mani on Apr 12, 2022 6:23:10 GMT
Hi, Assume if user is posting simply empty body({}). empty array([]) like below for negative validation,
. PATCH https://{redfish}/redfish/v1/Managers/Self/NetworkProtocol
request-body,
{
}
I hope in this case we need to return 400 bad request
Thanks, Mani
|
|
|
Post by mraineri on Apr 12, 2022 13:11:11 GMT
If the body is purely an empty array (like below), I would expect an error. All resources are JSON objects, and therefore using an array as the outer most portion of the body is not correct.
PATCH /redfish/v1/Managers/1/NetworkProtocol Content-Type: application/json
[] If the body is an empty object, I would not expect this to fail. This is simply a request with no properties to modify. It's very similar to using an empty object for object properties in a resource; it's valid JSON, and when tools step into the object to parse it, they find nothing to do and back out.
PATCH /redfish/v1/Managers/1/NetworkProtocol Content-Type: application/json
{}
|
|
|
Post by mraineri on Apr 12, 2022 13:16:14 GMT
We also have this statement in the spec regarding the empty JSON body in the request for PATCH. You can technically reject it.
"Services may accept a PATCH method with an empty JSON object, which indicates that the service should make no changes to the resource."
|
|
|
Post by AMI_Mani on Apr 12, 2022 18:13:27 GMT
Thanks for the details.
what response code we need to return for below
"Services may accept a PATCH method with an empty JSON object, which indicates that the service should make no changes to the resource."
there is no specific http code for no operation. Do we need to return http code 200 with extended message for no operation or http code 400 with extended message for no operation or http code 204 without message body
We have two use cases for PATCH https://{redfish}/redfish/v1/Managers/Self/NetworkProtocol
[case1]
{
"SSH":{}
}
Do we need to return http code 200 with extended message for no operation or http code 400 with extended message for no operation or http code 204 without message body
[case2]
{
} Do we need to return http code 200 with extended message for no operation or http code 400 with extended message for no operation or http code 204 without message body
How about handling above scenario for post operation?
Thanks, Mani
|
|
|
Post by mraineri on Apr 14, 2022 19:02:41 GMT
HTTP 400 would indicate the service rejected the request, meaning the service did not accept the empty JSON body. I would not expect this sort of behavior.
For either case, 200 OK would be the proper way to indicate the service accepted the request, and in the response body you can include "@message.ExtendedInfo" to leave additional message that nothing was changed. 204 No Content is also acceptable, but you won't be able to give any sort of "no operation" indicator.
|
|
|
Post by AMI_Mani on Apr 28, 2022 14:01:32 GMT
Thanks for details. I feel 204 No Content is not appropriate, since 204 No Content means Request succeeded, but no content is being returned in the body of the response. In this case nothing changed
Please comment about using 204 No Content
Thanks, Mani
|
|
|
Post by mraineri on Apr 29, 2022 13:54:05 GMT
Think about it from the semantics of the client: the client is specifying desired changes (in this case nothing), and so the service has nothing to perform to put the resource into the desired state. 204 can be appropriate here to tell the client that its request was satisfied and it can move on to other things. Just because nothing was changed doesn't necessarily mean this is an "error".
|
|
|
Post by AMI_archerwen on May 20, 2022 2:57:28 GMT
Hi,
If is below case could we also ignore (Return 204)?
{
"SSH":[] <- For this property, it is object but we give an array.
}
Thanks, Archer.
|
|
|
Post by jautor on May 20, 2022 18:05:18 GMT
Hi, If is below case could we also ignore (Return 204)? { "SSH":[] <- For this property, it is object but we give an array. } Thanks, Archer.
No, that PATCH would remove all the array elements. From the specification:
A PATCH request with fewer elements than in the current array shall remove the remaining elements of the array.
This is a PATCH with zero elements, so it removes all elements in the array.
Jeff
|
|
|
Post by mraineri on May 20, 2022 18:39:31 GMT
Specifically for that example though, I would expect that request to be rejected with a 400 response code. An array is an invalid data type for the property "SSH" in that resource.
But if the property in question is defined to be an array, then Jeff's response is correct.
|
|