[OASIS Issue Tracker] Commented: (CAMP-36) Use HTTP Patch and JSON Patch for updates to resources

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

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

Ashok Malhotra commented on CAMP-36:
------------------------------------

Not surprisingly, the OData folks have also been struggling with PUT vs. PATCH.  Here is the latest from 
Mike Pizzo of Microsoft 

"OData clients should always use PATCH, deprecate PUT

PUT semantics call for setting to null any properties not specified in the payload. PATCH semantics apply the specified properties but leave unspecified properties unchanged.

Specifying that clients ALWAYS use PATCH for updates is much safer for round-tripping data. For example, open properties, aggregated values, additive schema changes, and computed projections could all add additional properties to the payload that the client should be able to safely ignore. If the client uses PATCH to update then they do not lose information, but if the client ignores properties and uses PUT to update they will likely lose data in round-tripping."

The one concern I had with PATCH is whether there is sufficient uptake for PATCH.  So this comment is reassuring.


> Use HTTP Patch and JSON Patch for updates to resources
> ------------------------------------------------------
>
>                 Key: CAMP-36
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-36
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: New Feature
>          Components: Spec
>            Reporter: Anish Karmarkar
>            Assignee: Adrian Otto
>            Priority: Critical
>
> HTTP PUT semantics say that if a resource exists at the specified URI then it is completely overwritten on success (modulo side-effects). The correct RESTful way to update a resource is to use HTTP PATCH (http://tools.ietf.org/html/rfc5789).
> This was considered in the collaboration that created CAMP 1.0, but at that time there was no JSON-specific PATCH format. HTTP PATCH does not define a format, as it is envisioned that different applications, formats would have different needs. Eg, a XML patch format will be different from JSON. Since then the the IETF Applications Area Working Group has made a lot of progress on the JSON Patch format (http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-07). This spec allows one to modify an existing JSON resource by adding, deleting, moving, replacing properties and array/array elements. This spec is expected to go IETF Last Call soon and RFC by Q12013.
> Link to CAMP-34
> List of implementations are at: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch
> Nascent test suite: https://github.com/json-patch/json-patch-tests
> In addition to updating resources the "right" RESTful way by using PATCH, this also gets us out of the discussions and contortions around read-only attribute/immutable attributes (https://tools.oasis-open.org/issues/browse/CAMP-34). It also gets us out of using the SelectAttr query parameter to subset a resource (which some of us where uncomfortable with).

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