[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-36) Use HTTP Patch and JSON Patch for updates to resources
[ http://tools.oasis-open.org/issues/browse/CAMP-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32243#action_32243 ]
Gilbert Pilz commented on CAMP-36:
----------------------------------
I've made some initial forrays into implementing JSON Patch in nCAMP. My take is that it isn't that different from implementing PUT *except* you get to omit a whole bunch of up-front gorp in which you try to figure out what the user *really* wanted to do (e.g. by comparing various attributes, etc). It certainly is a whole lot cleaner than trying to implement PUT with "SelectAttr" support - which has a bunch of nasty corner cases like handling empty request bodies, etc. The real work involves in (a) figuring out if the user is allowed to make the change they have requested, (b) applying the semantics of the requested change to the system. JSON Patch lets you concentrate on these tasks and reduces the risks of introducing parsing/interpretation bugs on the front side.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]