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=31891#action_31891 ] 

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

I suggest using PATCH (http://tools.ietf.org/html/rfc5789). Simply define PUT operations as complete replacements for resources. Regardless of the HTTP method used, if values for read-only attributes are different than the current resource, an error needs to be returned. A time/date string may be different, as long as it converts to the stored Time/Date value in accordance with ISO8601.

Support PATCH with at least "Accept-Patch: application/json", such that any existing attribute specified is overwritten, new attributes are added, and if attributes are to be deleted, that they be expressed with a null value.

Example:

Starting Resource:
{
  "uri" : "http://some.example.com/18903/Assembly/1";,
  "name" : "/examples",
  "description" : "A smart assembly",
  "created" : "2012-11-14T00:00Z",
  "nonsense" : "a value we will remove later"
} 

HTTP PATCH Body:
{
  "uri" : "http://some.example.com/18903/Assembly/1";,
  "name" : "/examples",
  "description" : "An assembly",
  "created" : "2012-11-14T02:00-0200",
  "mustard" : "spicy",
  "nonsense" : null
} 

Resulting Entity:
{
  "uri" : "http://some.example.com/18903/Assembly/1";,
  "name" : "/examples",
  "description" : "An assembly",
  "created" : "2012-11-14T00:00Z",
  "mustard" : "spicy"
} 

Note that in the PATCH (1) the "created" date/time was given as a different string with an equivalent value, (2) the "description" attribute was changed, (3) The "mustard" attribute was added, and (4) the "nonsense" attribute was removed.

> 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]