Re: [scim] Request for Input

[Phil Hunt <[e-mail]>]

The trade off here is that the simple request you propose becomes complex because multiple operations must be completed against a resource rather then completing all changes in a single albeit somewhat more complex patch.

The RESTful model now becomes more complex because now we have both a Resource level set of verbs and then we have attribute level verbs.

Finally, it seems doubtful you could get rid of the current PATCH operation - by adding simple value modification proposed below, the spec would now have two ways of modifying things through 2 different RESTful models (per above). 

Overall, the spec gets much longer and more complex because it has multiple choices and RESTful verb models.

Aside: We've talked at length about positional identifies before. The trouble with value identifiers is managing all those keys and requiring the client to look them up before deleting. In practice it seems simplest to just specify the value you want deleted and let the server sort it out on the server side (avoiding extra request/responses). The limitation of the server-side value key approach is you cannot have duplicate values. In general this seems reasonable.

Another option that was considered is the JSON Patch draft. http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10
It works reasonably well when you know the entire contents of a JSON record/document. It's path construct doesn't really lend itself well to a Resource where the full document may not be available at the time of the PATCH.  In other words, the SCIM operation is to patch a remote object rather than a JSON document in hand.  In the end, it has the same limitation as the value identifiers. In particular for large groups, we want to avoid downloading the entire group just to allow the client to be able to patch it.  It's also worth noting that a SCIM client may not be allowed to know about the entire set of members in a SCIM Group.

A subtle tweak to the current PATCH that makes it more readable and less cryptic might be all we really need.

Phil

@independentid
www.independentid.com
[e-mail]





On 2013-03-31, at 11:47 AM, Samuel Erdtman wrote:

> I would vote for the simplest solution that solves the problem, I think Kelly raises a point that makes PUT and DELETE harder to get as clean as in the examples I.e. there is no single unique id for most multivalued attributes, the value attribute could be the same for several attributes e.g. Same phone number could be used for both mobile and work then it is the combination value and type that makes it unique. (With the current discussion on not requiring global unique id's for the combined set group and user will have the same problem if not required unique)
> 
> The solution might be to something like this:
> PUT /Groups/<group-Id>/<attribute>/
> e.g. 
> PUT /Groups/<group-Id>/members/
> 
> DELETE /Groups/<group-Id>/<attribute>/<type>/<value>
> e.g. 
> DELETE /Groups/<group-Id>/members/User/<value>
> 
> We could also allow replace in one operation by doing put to a uniquely identified attribute:
> PUT /Groups/<group-Id>/<attribute>/<type>/<value>
> e.g. 
> PUT /Groups/<group-Id>/members/User/<value>
> 
> In case we go for a solution like this I think that we also should simplify or remove PATCH operation. We could do singe attribute delete, add and update like this:
> PUT /Groups/<group-Id>/<attribute> (add or update attribute)
> PUT /Groups/<group-Id>/<attribute> (remove attribute)
> This has the disadvantage towards patch that you can only handle one attribute at the time or the full resource object.
> 
> Finally I would like to remind everyone that we have had the discussion of adding an "unique" identifier to the attributes in a multivalued attribute and the strongest argument against was that it is not possible when putting SCIM on top of an existing data source.
> 
> 
> Sent from my iPhone
> 
> On 28 mar 2013, at 18:54, "Erik Wahlström" <[e-mail]> wrote:
> 
>> +1
>> Rather make patch mandatory before adding functionality to PUT and DELETE. Just for simplicity. 
>> / Erik
>> 
>> On Mar 28, 2013, at 2:10 PM, Kelly Grizzle wrote:
>> 
>>> PATCH was added specifically to address the “changing membership of a large group” use case.  The POST/DELETE to the members endpoint was considered when looking into PATCH, but unfortunately this does not work in the general case.  Specifically, this only works if the list elements have a unique identifier, so it fell apart when trying to apply this to adding/removing addresses (which do not have a unique identifier).
>>>  
>>> I’m not convinced that we need to add another mechanism to solve this use case, but I do agree that PATCH could be simplified.
>>>  
>>> --Kelly
>>>  
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Phil Hunt
>>> Sent: Wednesday, March 27, 2013 7:02 PM
>>> To: Alexandre Santos
>>> Cc: [e-mail]
>>> Subject: Re: [scim] Request for Input
>>>  
>>> I think this may fit in with our discussion of adjusting PATCH to work better with multi-value and complex attributes (ticket 18).
>>>  
>>> So far, we've been avoiding extended paths that go within the Resource entity (e.g. to address specific attributes).
>>>  
>>> If you were to do the item below, I think you would have to add the attribute name to the path at the very least.
>>>  
>>> PUT /Groups/<groupid>/members/Users/<userid>
>>>  
>>> Still I think that may have problems if the member is actual a URL rather then a simple UUID.
>>>  
>>> Phil
>>>  
>>> @independentid
>>> www.independentid.com
>>> [e-mail]
>>> 
>>>  
>>> 
>>> 
>>>  
>>> On 2013-03-27, at 4:01 PM, Alexandre Santos wrote:
>>> 
>>> 
>>> For groups with many users (>10k) it becomes problematic to do POSTs or PUTs. The only alternative would be PATCH. However PATCH is not mandatory.
>>>  
>>> For this reason we would like to request your input for the following proposal: allow membership changes via PUT and DELETE.
>>>  
>>> For this the PUT and DELETE commands would be in the format:
>>> PUT /Groups/<groupId>/user/<userId> - to add a user to a group
>>> DELETE /Groups/<groupId>/user/<userId> - to remove the user from the group
>>>  
>>> Thank you,
>>> 
>>> Alexandre Santos  | Sr. Development Engineer
>>> PingIdentity  |   www.pingidentity.com
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> O: 604.697.7056
>>> Email: [e-mail]
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> Connect with Ping
>>> Twitter: @pingidentity
>>> LinkedIn Group: Ping's Identity Cloud    
>>> Facebook.com/pingidentitypage
>>> _______________________________________________
>>> scim mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/scim
>>>  
>>> _______________________________________________
>>> scim mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/scim
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim