[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (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:all-tabpanel ] Martin Chapman updated CAMP-36: -------------------------------- Description: 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). was: 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. 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). Priority: Critical (was: Major) > 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]