Subject: [scim] Questions on read-only attribute handling in POST/PUT/PATCH

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Sep 2013 10:54:33 -0700

I'd like to discuss handling of read-only attributes in POST/PUT/PATCH:

For example, the PUT operation appears to allows read-only attribute appear to be written for the convenience of the client.
> 3.3.1.  Modifying with PUT
> 
> 
> 
>    PUT performs a full update.  Consumers must retrieve the entire
>    Resource and PUT the desired modifications as the operation
>    overwrites all previously stored data with the exception of the
>    password attribute.  If the password attribute of the User resource
>    is unspecified, it should be left in-tact.  Since this performs a
>    full update, Consumers MAY send read-only attributes of the retrieved
>    resource and the Service Provider MUST ignore any read-only
>    attributes that are present in the payload of a PUT request.  Unless
>    otherwise specified a successful PUT operation returns a 200 OK
>    response code and the entire Resource within the response body,
>    enabling the Consumer to correlate the Consumer's and Provider's
>    views of the updated Resource.  Example:
Makes sense as a convenience so a SCIM client doesn't have to remove read-only attributes from a GET response before using it for a PUT request. So, this is a case where including read only attributes in the request is allowed.

Should the same could go for POST (create)? 
Let's say I do a GET /Users/xxxx on a specific user which returns the complete resource including all attributes in the GET response. Now I just want to copy / modify that json response content and pass it to a POST. Should clients be allowed to include read-only attributes like clients can for PUT?

Should PATCH exclude read-only attributes?
A PATCH request should not include read-only attributes since it's a partial resource update request.

If we decide to support "immutable" attributes, should they be treated the same way as read-only once set?

With regards to update responses:

When a User is patched should it return the entire new object? 
I notice that PATCH is unclear on what is returned on a successful response.  In one example it says the server can return nothing or everything in non-normative text. I guess the issue here is that when you PATCH a large group, you don't want the whole group returned.   What about for other objects like Users?

What attributes are returned on success?
As for what attributes are returned on a PUT/POST/PATCH successful operation, I would suggest we return the "default" attributes -- the ones you get when performing a query with no attributes list.  That said, one could argue etag and timestamp attributes should be returned too.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kiran Ayyagari <[email-masked]>
Date: Wed, 25 Sep 2013 23:42:10 +0530

On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt <[email-masked]> wrote:

> For example, the PUT operation appears to allows read-only attribute
> appear to be written for the convenience of the client.
>
> 3.3.1 <http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.3.1>.  Modifying with PUT
>
> Makes sense as a convenience so a SCIM client doesn't have to remove
> read-only attributes from a GET response before using it for a PUT request.
> So, this is a case where including read only attributes in the request is
> allowed.
>
> *Should the same could go for POST (create)? *
> Let's say I do a GET /Users/xxxx on a specific user which returns the
> complete resource including all attributes in the GET response. Now I just
> want to copy / modify that json response content and pass it to a POST.
> Should clients be allowed to include read-only attributes like clients can
> for PUT?
>
> *Should PATCH exclude read-only attributes?*
IMO, the provider should make use of the schema and ignore all the
read-only attributes
cause providers are already forced by the spec to do this in the case of PUT

>
> *If we decide to support "immutable" attributes, should they be treated
> the same way as read-only once set?*
>
> *When a User is patched should it return the entire new object? *
> I notice that PATCH is unclear on what is returned on a successful
> response.  In one example it says the server can return nothing or
> everything in non-normative text. I guess the issue here is that when you
> PATCH a large group, you don't want the whole group returned.   What about
> for other objects like Users?
>
> *What attributes are returned on success?*
> As for what attributes are returned on a PUT/POST/PATCH successful
> operation, I would suggest we return the "default" attributes -- the ones
> you get when performing a query with no attributes list.  That said, one
> could argue etag and timestamp attributes should be returned too.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

-- 
Kiran Ayyagari
http://keydap.com

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Sep 2013 11:21:30 -0700

Kiran,

So what happens if the PATCH is only to an attribute that is read-only?  Should the operation fail?  Or should it appear to succeed while nothing happens?

A further question.  Let's assume we ignore attributes that are read-only for PUT/POST/PATCH.

What happens if the client changes the read-only value from what the server already has?  Should that cause an error?  IOW…should the attempted modify of a read-only value only be ignored if the client doesn't actually attempt to change the value?

Also, there was special handling of password on the PUT operation where it can be omitted from the PUT and the value is maintained. Is this "sticky" value setting something that should apply to other attributes and be reflected in schema?

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-09-25, at 11:12 AM, Kiran Ayyagari <[email-masked]> wrote:

> IMO, the provider should make use of the schema and ignore all the read-only attributes

---

From: Kiran Ayyagari <[email-masked]>
Date: Thu, 26 Sep 2013 00:01:31 +0530

On Wed, Sep 25, 2013 at 11:51 PM, Phil Hunt <[email-masked]> wrote:

> Kiran,
>
> So what happens if the PATCH is only to an attribute that is read-only?
>  Should the operation fail?  Or should it appear to succeed while nothing
> happens?
>
I would consider it to be successful though nothing happens

> What happens if the client changes the read-only value from what the
> server already has?  Should that cause an error?  IOW…should the attempted
> modify of a read-only value only be ignored if the client doesn't actually
> attempt to change the value?
>
yes, it should be ignored, and this is the main reason for keeping an
attribute read-only, which is to prevent
a client from updating it irrespective of the value sent by the client

>
> Also, there was special handling of password on the PUT operation where it
> can be omitted from the PUT and the value is maintained. Is this "sticky"
> value setting something that should apply to other attributes and be
> reflected in schema?
>
yes, and will be great from an implementor's point of view, otherwise I
imagine many hard-coded
attribute name literals in code to handle the special cases like these.

thanks Phil

-- 
Kiran Ayyagari
http://keydap.com