[OASIS Issue Tracker] Commented: (CAMP-34) Immutable and read-only attributes in the REST world

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31941#action_31941 ] 

Adrian Otto commented on CAMP-34:
---------------------------------

Recognize that the draft for "JSON Patch" is considerably more complex than what I've proposed. Referring to it may raise further questions about whether "JSON Patch" should be implemented fully or partially. Supporting a complete implementation of "JSON Patch" is more involved than just allowing what effectively amounts to editing a resource, because it calls for operations such as MOVE and COPY which are beyond the scope of what we have considered for modification of resources.

One option we could consider is to use a simplistic approach such as the one described above, and if "JSON Patch" becomes an RFC, to use that going forward in a higher version of the spec. This may reduce the complexity somewhat for the first CAMP implementations, which may result in slightly more rapid adoption of the spec. It would also require clients and servers to be changed later when we change the scheme to conform to "JSON PATCH".

Another option would be to describe a solution that conforms with "JSON Patch" in our spec to begin with, and later remove our description and refer to the "JSON Patch" RFC number once it exists. The benefit of this approach is that it would require less software changes over the life of an implementation, both on the server side, and the client side.

Yet another benefit of using "JSON Patch" is that you can define a pipeline of patch operations, rather than just one update per request, which would reduce the protocol "chat" frequency over the network if a lot of changes are requested.

We can remove discussion relating to date strings, since we resolved CAMP-33 in a way that there is only one valid string representation for each date/time value.

> Immutable and read-only attributes in the REST world
> ----------------------------------------------------
>
>                 Key: CAMP-34
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-34
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Anish Karmarkar
>
> We have a notion of immutable attributes (section 5.2.2) and read-only attribute (section 5.2.3) for resources. By definition these attributes cannot be changed by the client. One example of such an attribute is 'created' (section 5.3.4). When a client updates the resource (using PUT), does it include these attributes? The semantics of PUT say that PUT overwrites everything at the specified resources. This implies that the client cannot exclude any attributes. PUT cannot be used for partial updates (see http://tech.groups.yahoo.com/group/rest-discuss/message/17421). This brings up some interesting questions:
> 1) What should the server do if the attribute 'created' (or a similar attribute) is not included in the PUT? Error, ignore the omission, or something else?
> 2) What should the server do if the attribute 'created' (or a similar attribute) is changed by the client in the PUT? Error, ignore the change, or something else?
> 3) Is the server required to check changes to read-only attributes?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira