Hi Sarubi, 1. According to the SCIM protocol specification, if the "path" attribute is > not provided in the request then we assume that the target location is > resource itself. > > If omitted, the target location is assumed to be the resource >> itself. The "value" parameter contains a set of attributes to be >> added to the resource. > > > But if the path attribute is present in the request but path attribute > value is empty. In this case, how we are going to treat the request, are we > going to assume the target location as a resource itself and process the > Patch Add operation or going to throw an error? if we are going to throw an > error what should be the error message? >
As the path is an optional parameter if the request contains path parameter, then we need to honour it and throw an error message if the value is empty. 2. According to the specification, path attribute can have a filter > condition. as an example, > > "path":"addresses[type eq \"work\"]" > > Where we going to patch the address its type is equal to work. > > Under the Patch Add operation, we haven't specifically instructed how we > need to handle it. > So how we are going to handle this kind of use-case? > But this is kind of Patch Replace upon provided condition. In Patch > Replace it has been explained how we going to treat. > So shall we treat this kind of operation as patch replace? > As the spec does not specify anything for patch add, lets treat this operations in the same way as patch replace. Thanks, Hasanthi On Wed, Jun 5, 2019 at 12:15 PM Sarubi Thillainathan <[email protected]> wrote: > Hi All, > > Currently, I'm working on to support the "path" attribute in the SCIM > PATCH ADD operation. While working on that, I come across some confusion on > how we are going to handle the following few use-cases. > 1. According to the SCIM protocol specification, if the "path" attribute > is not provided in the request then we assume that the target location is > resource itself. > > If omitted, the target location is assumed to be the resource >> itself. The "value" parameter contains a set of attributes to be >> added to the resource. > > > But if the path attribute is present in the request but path attribute > value is empty. In this case, how we are going to treat the request, are we > going to assume the target location as a resource itself and process the > Patch Add operation or going to throw an error? if we are going to throw an > error what should be the error message? > > 2. According to the specification, path attribute can have a filter > condition. as an example, > > "path":"addresses[type eq \"work\"]" > > Where we going to patch the address its type is equal to work. > > Under the Patch Add operation, we haven't specifically instructed how we > need to handle it. > So how we are going to handle this kind of use-case? > But this is kind of Patch Replace upon provided condition. In Patch > Replace it has been explained how we going to treat. > So shall we treat this kind of operation as patch replace? > > Please provide your guidance around this. > [1] https://tools.ietf.org/html/rfc7644#section-3.5.2.1 > > Thanks, > Sarubi. > -- > *Sarubi Thillainathan* | Software Engineer | WSO2 Inc. > (m) +94 (0) 76 684 9101 | (e) [email protected],[email protected] > > *[image: https://wso2.com/signature] <https://wso2.com/signature>* > -- Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc. (m) +94718407133 | (w) +94112145345 | Email: [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
