HTTP method differentiation between partial and full updates.

[SebastianEdwards]

Hello Mike,

I was wondering if you had any plans around introducing the PATCH method to the spec to handle partial or non-idempotent updates to a resource. This would be in contrast to the PUT method where it should be assumed the full representation of the resource is being transmitted.

I know there has been a lot of talk about this topic recently with at least one popular web framework (Rails) making the switch to differentiating between these two levels of update.

Very interested to hear your thoughts on the matter and thanks for all the work you've done on Collection+JSON thus far.

[mamund]

Sebastian:

That's a good question.

I don't have any plans at the moment, but I can see it might be helpful.

first, to support PATCH, we'd need to select a PATCH-compliant media type. collection+JSON won't work itself as it does not have the proper semantic elements (and I', not interested in expanding collection+JSON for this). I know there is a JSON PATCH format going through I-D now[1]. I haven't spent too much time w/ it yet. anyone else familiar w/ it?

second (once we select a PATCH-y media type), we'd need an element in the representation to signal PATCH is supported. I assume this would be for a single "item" (not patching a list). I suspect we can use the link collection at the top of the document for that w/ a proper identifier:

links: [ {href: URI, rel:"patch"} ]

how does that sound as a starter?

Mike

[1] http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-01

mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me

On Tue, Apr 3, 2012 at 18:41, Sebastian Edwards [email protected] wrote:

Hello Mike,

I was wondering if you had any plans around introducing the PATCH method to the spec to handle partial or non-idempotent updates to a resource. This would be in contrast to the PUT method where it should be assumed the full representation of the resource is being transmitted.

I know there has been a lot of talk about this topic recently with at least one popular web framework (Rails) making the switch to differentiating between these two levels of update.

Very interested to hear your thoughts on the matter and thanks for all the work you've done on Collection+JSON thus far.

---

Reply to this email directly or view it on GitHub: https://github.com/mamund/collection-json/issues/2

[SebastianEdwards]

Ah interesting, I had not seen that draft before. I was actually imagining a more simplistic model then this however..

Would the following approach be workable? The client would, when constructing update requests, choose to either use the entire 'template' array to build the request object and PUT this to the server or choose to use only part of the 'template' array to construct the request and then use the PATCH method to submit this. This approach, naive as it may be, would allow for add/replace operations to be run against the target resource without requiring any structural changes to the media type (would still use the 'template' array; the client would just pick the relavent keys to update) nor any additional rel signals.

[mamund]

yes, JSON-Patch does seem rather involved. again, i haven't spent enough time w/ it to make a clear judgement.

PARTIAL UPDATE EXTENSION first, if you'd like to implement your own support for a "partial" update in CJ, i have no problem w/ you adding an extension. i suggest the same initial pattern i described: add a link to the top-level collection w/ a meaningful rel so that clients can implement the extension. i suggest you use "partial" (or something similar) since it's possible at some future point we'll add full PATH support w/ a designated media type.

if you want to write it up and post it to the collection-json list, that'd be cool. i haven't yet added extension section here in the git repo, but will in the next month or so.

let me know if you're interested in pursuing an extension; i'd be happy to work w/ you to write it up and get it registered here for others to find and implement.

AMUNDSEN.PATCH+JSON second, i myself am not a fan of the use of the existing template, esp. since there is little to no concurrency-checking or field-level transaction support in a simple "partial update" pattern, but i can see it's attraction.

i've been experimenting by using a very simple construct:

PATCH /.... content-type application/vnd.amundsen.patch+json ...

{patch, add : [ {name:"..",...}. {name:"...", ...} ], update: [ {old: {name: "...",...}. new: {name:"...",...}}, {old: {name: "...",...}. new: {name:"...",...}} ], remove: [ {name:"..",...}. {name:"...", ...} ] }

note the inclusion of the "old" (or existing) item for update & remove, this is done to prevent changes to fields that already have been modified by someone else (concurrency checking). also, in my model, the add collection is only good if the "name" does not already exist for that item. finally, my implementation rejects the entire request if any of the changes fail (transaction support for field-level changes).

this is not a perfect model (there is no support for "test" mode, like in JSON-patch), but it has been working for me.

i've been using this fora couple internal projects and it's been working (for the most part). but, really, it's a different media type (diff than CJ) w/ a different set of processing rules. i have yet to write them up, tho :(

mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me

On Tue, Apr 3, 2012 at 20:47, Sebastian Edwards [email protected] wrote:

Ah interesting, I had not seen that draft before. I was actually imagining a more simplistic model then this however..

Would the following approach be workable? The client would, when constructing update requests, choose to either use the entire 'template' array to build the request object and PUT this to the server or choose to use only part of the 'template' array to construct the request and then use the PATCH method to submit this. This approach, naive as it may be, would allow for add/replace operations to be run against the target resource without requiring any structural changes to the media type (would still use the 'template' array; the client would just pick the relavent keys to update) nor any additional rel signals.

---

Reply to this email directly or view it on GitHub: https://github.com/mamund/collection-json/issues/2#issuecomment-4945278