|
|
Post by AMI_Mani on Jan 21, 2022 18:33:02 GMT
Hi,
Assume user is giving patch request for Integer property using duplicate attributes with different value in request body
{
testvalue:1,
testvalue:2,
testvalue:3
}
While processing this request, we can return bad request mentioning as duplicate value or set value as 3.
Please suggest which option to use or it can be implementation specific
Thanks,
Mani
|
|
|
|
Post by jautor on Jan 21, 2022 20:07:02 GMT
This is not valid JSON, since the property is duplicated, so I would expect an error using the Base message "PropertyDuplicate" or an invalid JSON message "InvalidJSON". You certainly should not accept the "last" value regardless, as JSON payloads are not ordered (so even if it was valid, you can't know which was the "last" value).
Jeff
|
|
|
|
Post by AMI_Mani on Jan 22, 2022 4:37:49 GMT
Hi Jeff,
Got it. I missed PropertyDuplicate in message registry and it's apt to use
Thanks,
Mani
|
|
|
|
Post by AMI_Mani on Oct 22, 2022 9:44:33 GMT
Hi Jeff, If user is trying to patch same value, do we need to give 400 bad request or it can vary based on service implementation(URI specific)? Assume user is giving patch request for Integer property with same value in request body(already testvalue is 1) { testvalue:1 } I'm unable to find standard message registry from redfish.dmtf.org/registries/Base.1.14.0.json, please add your comments Thanks, Mani |
|
|
|
Post by jautor on Oct 22, 2022 14:56:21 GMT
Hi Jeff, If user is trying to patch same value, do we need to give 400 bad request or it can vary based on service implementation(URI specific)? Assume user is giving patch request for Integer property with same value in request body(already testvalue is 1) { testvalue:1 } I'm unable to find standard message registry from redfish.dmtf.org/registries/Base.1.14.0.json, please add your comments Thanks, Mani No, this is not an error. Any RESTful interface, by definition, must allow for this case and treat it just like any other successful modification request. You should return 200 Success in this case. Jeff |
|
|
|
Post by AMI_Mani on Oct 22, 2022 17:34:09 GMT
Hi Jeff,
Thanks for reply. In this case do we need to update etag also if we patch with same value or just simply give 200 with success message and not update etag
Assum if we have some constraint of updating same value, can we give bad request?
Thanks,
Mani
|
|
|
|
Post by mraineri on Oct 24, 2022 16:52:31 GMT
Updating the ETag is entirely dependent on how you compute your ETag. If your algorithm simply uses contents of the resource's payload and nothing else, then there would not be any change in the ETag. But if your algorithm has other factors (like modification timestamps), then I can see the ETag changing. Redfish doesn't mandate a specific mechanism for computing the ETag.
|
|
|
|
Post by AMI_Mani on Oct 24, 2022 18:28:53 GMT
Thanks for reply.
Assume if we have some constraint of updating same value for some resources, can we give bad request or needs to return 200 success message for all cases?
Thanks,
Mani
|
|
|
|
Post by jautor on Oct 25, 2022 16:27:15 GMT
Assume if we have some constraint of updating same value for some resources, can we give bad request or needs to return 200 success message for all cases? That should not be the case for any Redfish resource or property - as the interface is defined using REST semantics. If there is an "error" or the R/W property is implemented as read-only (in a particular resource or for the entire service), those are acceptable error conditions. But if there is something underneath the interface that has some restrictions, those should be dealt with and not be reflected in the REST interface... Jeff |
|
|
|
Post by AMI_Mani on Jan 31, 2023 11:12:56 GMT
Hi Jeff, As per The JavaScript Object Notation (JSON) Data Interchange Format www.rfc-editor.org/rfc/rfc8259#section-4An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicatesIt can be implementation specific and we can take last value for duplicated attributes instead of returning bad request { testvalue:1, testvalue:2, testvalue:3 } Assume we have lot of attributes in request body and comparing for duplicate attribute may take time , some json libraries won't support for finding duplicate attributes. Please confirm whether we need to give "PropertyDuplicate" /an invalid JSON message "InvalidJSON" or take last value and process request Thanks, Mani |
|
|
|
Post by jautor on Feb 1, 2023 17:23:48 GMT
I'll bring this up with the group to get some feedback - but while our preference is to detect and report an error (as above), if the JSON libraries don't detect the condition, well, it will be "unpredictable" just as the JSON RFC states, and probably nothing more we can say about it.
Jeff
|
|
|
|
Post by AMI_Mani on May 10, 2023 19:18:57 GMT
Hi Jeff,
Do we have any further update on this? Whether implementation can take last value of Attributes if duplicated, please confirm
Thanks,
Mani
|
|
|
|
Post by mraineri on May 12, 2023 19:19:58 GMT
You can use either "PropertyDuplicate" or "InvalidJSON"; it's really dependent on your JSON processing. In either case, the client needs to fix their request. If your JSON processor can detect duplicates when processing the JSON request, then that's great; that's a better message since it's more specific. If your JSON processor simply crashes because of the duplicate properties, you can return InvalidJSON; that's good enough. Accepting the request would encourage bad client behavior since it's not valid to send requests with multiple instances of the same property.
|
|
