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