OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Anish Karmarkar commented on CAMP-34:
-------------------------------------

I like the idea of using PATCH. It is becoming well accepted in the REST community. But HTTP PATCH is only a partial solution. It allows us to avoid misusing PUT semantics. But by design (and correctly IMHO) HTTP PATCH does not address the issue of format. Different kinds of resource would need different formats. The IETF Applications Area Working Group is actively working on a json-patch format that defines a media-type and the format for adding, deleting, copying, moving properties/arrays within  resource. They recently updated the internet-draft http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-07. I'm told that they are going to go to IETF Last Call "Real Soon" and that it is likely to become an RFC Q12013 (fingers crossed). I think we should track this closely. This is within the timeframe of CAMP spec. If it becomes an RFC in Q12013, I think we should use it in our spec.

> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]