You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by "Paul C. Bryan" <pa...@forgerock.com> on 2011/04/20 20:31:13 UTC
JSON-Patch
I just posted an informational Internet-Draft regarding a JSON media
type to support HTTP PATCH partial modifications—something I've desired
in CouchDB for a while, since this thread:
http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
http://tools.ietf.org/html/draft-pbryan-json-patch-00
Any feedback would be appreciated.
Paul
Re: JSON-Patch
Posted by "Paul C. Bryan" <pa...@forgerock.com>.
On Wed, 2011-04-20 at 21:59 +0200, Aurélien Bénel wrote:
> True, PATCH could be idempotent... It just depends on your patch format.
It depends less on your patch format, and more on the reliance on
preconditions (e.g. If-Match, If-Not-Match).
> I just had a look at your patch operations specification:
> - When you add or remove a key/value, this is idempotent.
> - However, when you add or remove an array element based on an index, this is not.
HTTP PATCH idempotency is for the entire resource being modified. It
intends the whole patch document to be applied or not.
Paul
Re: JSON-Patch
Posted by sleepnova <wa...@gmail.com>.
Maybe it's viable to use different Content-Type to switch different state
transition formates. (PATCH or ACTION verb)
For example:
patch
json
javascript
Each one has it's own advantages on describing state transfer.
For example, it's not easy to create or apply a text (or binary) patch with
in a browser environment.
2011/4/21 Paul Davis <pa...@gmail.com>
> Skimming RFC3284 it appears to be byte based which seems quite
> incompatible with couchdb internals.
>
> On Wed, Apr 20, 2011 at 5:37 PM, Robert Newson <ro...@gmail.com>
> wrote:
> > supporting RFC 3284 format for PUT has been proposed before, and it's
> generic.
> >
> > B.
> >
> > On 20 April 2011 21:55, sleepnova <wa...@gmail.com> wrote:
> >> A sudo patch for demonstration.
> >>
> >> if(doc._rev=="07769cff70767095e4fb525dc9000b6e"){
> >> //Put your patch here
> >> }
> >>
> >> I think above patch would be idempotent even when add or remove an array
> >> element based on an index.
> >>
> >> 2011/4/21 sleepnova <wa...@gmail.com>
> >>
> >>> A patch which checks document version number might solve this problem.
> >>> similar to a git commit log
> >>>
> >>>
> >>> 2011/4/21 Aurélien Bénel <au...@utt.fr>
> >>>
> >>>> Dear Paul,
> >>>>
> >>>> > On the other hand, there's nothing inherently wrong with the PATCH
> verb
> >>>>
> >>>> True, PATCH could be idempotent... It just depends on your patch
> format.
> >>>>
> >>>> I just had a look at your patch operations specification:
> >>>> - When you add or remove a key/value, this is idempotent.
> >>>> - However, when you add or remove an array element based on an index,
> this
> >>>> is not.
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Aurélien
> >>>
> >>>
> >>> --
> >>> - sleepnova
> >>>
> >>
> >> --
> >> - sleepnova
> >>
> >
>
--
- sleepnova
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
Skimming RFC3284 it appears to be byte based which seems quite
incompatible with couchdb internals.
On Wed, Apr 20, 2011 at 5:37 PM, Robert Newson <ro...@gmail.com> wrote:
> supporting RFC 3284 format for PUT has been proposed before, and it's generic.
>
> B.
>
> On 20 April 2011 21:55, sleepnova <wa...@gmail.com> wrote:
>> A sudo patch for demonstration.
>>
>> if(doc._rev=="07769cff70767095e4fb525dc9000b6e"){
>> //Put your patch here
>> }
>>
>> I think above patch would be idempotent even when add or remove an array
>> element based on an index.
>>
>> 2011/4/21 sleepnova <wa...@gmail.com>
>>
>>> A patch which checks document version number might solve this problem.
>>> similar to a git commit log
>>>
>>>
>>> 2011/4/21 Aurélien Bénel <au...@utt.fr>
>>>
>>>> Dear Paul,
>>>>
>>>> > On the other hand, there's nothing inherently wrong with the PATCH verb
>>>>
>>>> True, PATCH could be idempotent... It just depends on your patch format.
>>>>
>>>> I just had a look at your patch operations specification:
>>>> - When you add or remove a key/value, this is idempotent.
>>>> - However, when you add or remove an array element based on an index, this
>>>> is not.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Aurélien
>>>
>>>
>>> --
>>> - sleepnova
>>>
>>
>> --
>> - sleepnova
>>
>
Re: JSON-Patch
Posted by Robert Newson <ro...@gmail.com>.
supporting RFC 3284 format for PUT has been proposed before, and it's generic.
B.
On 20 April 2011 21:55, sleepnova <wa...@gmail.com> wrote:
> A sudo patch for demonstration.
>
> if(doc._rev=="07769cff70767095e4fb525dc9000b6e"){
> //Put your patch here
> }
>
> I think above patch would be idempotent even when add or remove an array
> element based on an index.
>
> 2011/4/21 sleepnova <wa...@gmail.com>
>
>> A patch which checks document version number might solve this problem.
>> similar to a git commit log
>>
>>
>> 2011/4/21 Aurélien Bénel <au...@utt.fr>
>>
>>> Dear Paul,
>>>
>>> > On the other hand, there's nothing inherently wrong with the PATCH verb
>>>
>>> True, PATCH could be idempotent... It just depends on your patch format.
>>>
>>> I just had a look at your patch operations specification:
>>> - When you add or remove a key/value, this is idempotent.
>>> - However, when you add or remove an array element based on an index, this
>>> is not.
>>>
>>>
>>> Regards,
>>>
>>> Aurélien
>>
>>
>> --
>> - sleepnova
>>
>
> --
> - sleepnova
>
Re: JSON-Patch
Posted by sleepnova <wa...@gmail.com>.
A sudo patch for demonstration.
if(doc._rev=="07769cff70767095e4fb525dc9000b6e"){
//Put your patch here
}
I think above patch would be idempotent even when add or remove an array
element based on an index.
2011/4/21 sleepnova <wa...@gmail.com>
> A patch which checks document version number might solve this problem.
> similar to a git commit log
>
>
> 2011/4/21 Aurélien Bénel <au...@utt.fr>
>
>> Dear Paul,
>>
>> > On the other hand, there's nothing inherently wrong with the PATCH verb
>>
>> True, PATCH could be idempotent... It just depends on your patch format.
>>
>> I just had a look at your patch operations specification:
>> - When you add or remove a key/value, this is idempotent.
>> - However, when you add or remove an array element based on an index, this
>> is not.
>>
>>
>> Regards,
>>
>> Aurélien
>
>
> --
> - sleepnova
>
--
- sleepnova
Re: JSON-Patch
Posted by sleepnova <wa...@gmail.com>.
A patch which checks document version number might solve this problem.
similar to a git commit log
2011/4/21 Aurélien Bénel <au...@utt.fr>
> Dear Paul,
>
> > On the other hand, there's nothing inherently wrong with the PATCH verb
>
> True, PATCH could be idempotent... It just depends on your patch format.
>
> I just had a look at your patch operations specification:
> - When you add or remove a key/value, this is idempotent.
> - However, when you add or remove an array element based on an index, this
> is not.
>
>
> Regards,
>
> Aurélien
--
- sleepnova
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Apr 20, 2011 at 3:59 PM, Aurélien Bénel <au...@utt.fr> wrote:
> Dear Paul,
>
>> On the other hand, there's nothing inherently wrong with the PATCH verb
>
> True, PATCH could be idempotent... It just depends on your patch format.
>
> I just had a look at your patch operations specification:
> - When you add or remove a key/value, this is idempotent.
> - However, when you add or remove an array element based on an index, this is not.
>
>
> Regards,
>
> Aurélien
Ah, fair point. I should've said there's nothing inherently wrong with
submitting a diff via POST (not PUT). And in fact RFC 5789 says that
PATCH is not safe or idempotent.
On the other hand, I have no idea how that has anything to do with
REST. Of specific note, Fielding himself calls out the PATCH verb as
an acceptable extension of the underlying protocol for a REST API [1].
[1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Re: JSON-Patch
Posted by Aurélien Bénel <au...@utt.fr>.
Dear Paul,
> On the other hand, there's nothing inherently wrong with the PATCH verb
True, PATCH could be idempotent... It just depends on your patch format.
I just had a look at your patch operations specification:
- When you add or remove a key/value, this is idempotent.
- However, when you add or remove an array element based on an index, this is not.
Regards,
Aurélien
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Apr 20, 2011 at 2:59 PM, Aurélien Bénel <au...@utt.fr> wrote:
> Hi Paul,
>
>> I just posted an informational Internet-Draft regarding a JSON media
>> type to support HTTP PATCH partial modifications
>
> Thanks for sharing, this is really interesting.
>
> However, as far as I understand REST (applied to HTTP), the major pros of
> "transferring states" instead of procedure calls is that :
> - GET is safe,
> - PUT and DELETE are idempotent.
>
> Those 2 properties have really important impacts on scaling.
>
> Of course you can PATCH but this is not RESTful... and then, you don't get
> benefits from Fielding's architecture...
>
> Regards,
>
> Aurélien
In the end the HTTP part shouldn't be part of the specification.
On the other hand, there's nothing inherently wrong with the PATCH
verb or applying a diff in response to a PUT. This is merely an
attempt at reciprocating the byte-range functionality for writes.
Re: JSON-Patch
Posted by Aurélien Bénel <au...@utt.fr>.
Hi Paul,
> I just posted an informational Internet-Draft regarding a JSON media
> type to support HTTP PATCH partial modifications
Thanks for sharing, this is really interesting.
However, as far as I understand REST (applied to HTTP), the major pros
of "transferring states" instead of procedure calls is that :
- GET is safe,
- PUT and DELETE are idempotent.
Those 2 properties have really important impacts on scaling.
Of course you can PATCH but this is not RESTful... and then, you don't
get benefits from Fielding's architecture...
Regards,
Aurélien
Re: JSON-Patch
Posted by "Paul C. Bryan" <pa...@forgerock.com>.
I've setup a separate Google Group to discuss this topic:
https://groups.google.com/group/json-patch
Thanks,
Paul
On Wed, 2011-04-20 at 11:31 -0700, Paul C. Bryan wrote:
> I just posted an informational Internet-Draft regarding a JSON media
> type to support HTTP PATCH partial modifications—something I've desired
> in CouchDB for a while, since this thread:
> http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-00
>
> Any feedback would be appreciated.
>
> Paul
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Apr 20, 2011 at 3:10 PM, sleepnova <wa...@gmail.com> wrote:
> It would be nice to use Javascript to describe a patch.
>
Why would you want to tie a diff format for a data interchange format
to a specific language?
Re: JSON-Patch
Posted by sleepnova <wa...@gmail.com>.
It would be nice to use Javascript to describe a patch.
2011/4/21 Filipe David Manana <fd...@apache.org>
> This is very interesting.
> Thanks for the work and sharing it :)
>
> On Wed, Apr 20, 2011 at 7:31 PM, Paul C. Bryan <pa...@forgerock.com>
> wrote:
> > I just posted an informational Internet-Draft regarding a JSON media
> > type to support HTTP PATCH partial modifications—something I've desired
> > in CouchDB for a while, since this thread:
> > http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
> >
> > http://tools.ietf.org/html/draft-pbryan-json-patch-00
> >
> > Any feedback would be appreciated.
> >
> > Paul
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
--
- sleepnova
Re: JSON-Patch
Posted by Filipe David Manana <fd...@apache.org>.
This is very interesting.
Thanks for the work and sharing it :)
On Wed, Apr 20, 2011 at 7:31 PM, Paul C. Bryan <pa...@forgerock.com> wrote:
> I just posted an informational Internet-Draft regarding a JSON media
> type to support HTTP PATCH partial modifications—something I've desired
> in CouchDB for a while, since this thread:
> http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-00
>
> Any feedback would be appreciated.
>
> Paul
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: JSON-Patch
Posted by "Paul C. Bryan" <pa...@forgerock.com>.
On Wed, 2011-04-20 at 16:26 -0400, Paul Davis wrote:
> I could see mentioning them in a motivation section. On the other
> hand, mentioning PATCH in the error handling section seems
> inappropriate. Error conditions for JSON diffs should resolve around
> possible errors like inserting an element beyond the end of an array
> or at a negative offset or such things.
Point well taken. I will revise accordingly.
Paul
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Apr 20, 2011 at 4:04 PM, Paul C. Bryan <pa...@forgerock.com> wrote:
> On Wed, 2011-04-20 at 15:15 -0400, Paul Davis wrote:
>
> Thanks for the feedback.
>
>
>> On Wed, Apr 20, 2011 at 2:31 PM, Paul C. Bryan <pa...@forgerock.com> wrote:
>> > I just posted an informational Internet-Draft regarding a JSON media
>> > type to support HTTP PATCH partial modifications—something I've desired
>> > in CouchDB for a while, since this thread:
>> > http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
>> >
>> > http://tools.ietf.org/html/draft-pbryan-json-patch-00
>> >
>> > Any feedback would be appreciated.
>> >
>> > Paul
>> >
>>
>> Cool work. Though I would argue against relying on JSONPath in the
>> spec, because JSONPath has no spec itself. I did a fairly similar
>> thing to this but instead of using paths I added operations for moving
>> around the JSON object. There's code for it in a Python package [1]
>> that I'll try and remember to move to github later tonight.
>
>
>
> Yes, I went back and forth on the use of JSONPath. Eventually, I settled
> on using it because it does provide a well-defined format and the
> prospect of reinventing it put me off. I'm currently in the process of
> trying to get a stable subset of JSONPath published as an I-D as well.
>
Cool. When you have a draft make sure and post a link.
>
>> Also, I would remove all wording about HTTP from the specification.
>> Just because CouchDB might use the HTTP PATCH verb to apply JSON diffs
>> doesn't mean the diff format should be aware that HTTP even exists.
>> That's be like saying that unified diff's are only valid when applied
>> over email or something.
>>
>> [1] http://pypi.python.org/pypi/jsontools/0.1
>
>
> I only mean HTTP and HTTP PATCH to be as informative references—I would
> like there to be a patch document format for JSON that is used with HTTP
> PATCH. Maybe I can lighten—but not totally eliminate—my references to
> them? :-)
>
> Paul
>
>
I could see mentioning them in a motivation section. On the other
hand, mentioning PATCH in the error handling section seems
inappropriate. Error conditions for JSON diffs should resolve around
possible errors like inserting an element beyond the end of an array
or at a negative offset or such things.
Re: JSON-Patch
Posted by "Paul C. Bryan" <pa...@forgerock.com>.
On Wed, 2011-04-20 at 15:15 -0400, Paul Davis wrote:
Thanks for the feedback.
> On Wed, Apr 20, 2011 at 2:31 PM, Paul C. Bryan <pa...@forgerock.com> wrote:
> > I just posted an informational Internet-Draft regarding a JSON media
> > type to support HTTP PATCH partial modifications—something I've desired
> > in CouchDB for a while, since this thread:
> > http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
> >
> > http://tools.ietf.org/html/draft-pbryan-json-patch-00
> >
> > Any feedback would be appreciated.
> >
> > Paul
> >
>
> Cool work. Though I would argue against relying on JSONPath in the
> spec, because JSONPath has no spec itself. I did a fairly similar
> thing to this but instead of using paths I added operations for moving
> around the JSON object. There's code for it in a Python package [1]
> that I'll try and remember to move to github later tonight.
Yes, I went back and forth on the use of JSONPath. Eventually, I settled
on using it because it does provide a well-defined format and the
prospect of reinventing it put me off. I'm currently in the process of
trying to get a stable subset of JSONPath published as an I-D as well.
> Also, I would remove all wording about HTTP from the specification.
> Just because CouchDB might use the HTTP PATCH verb to apply JSON diffs
> doesn't mean the diff format should be aware that HTTP even exists.
> That's be like saying that unified diff's are only valid when applied
> over email or something.
>
> [1] http://pypi.python.org/pypi/jsontools/0.1
I only mean HTTP and HTTP PATCH to be as informative references—I would
like there to be a patch document format for JSON that is used with HTTP
PATCH. Maybe I can lighten—but not totally eliminate—my references to
them? :-)
Paul
Re: JSON-Patch
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Apr 20, 2011 at 2:31 PM, Paul C. Bryan <pa...@forgerock.com> wrote:
> I just posted an informational Internet-Draft regarding a JSON media
> type to support HTTP PATCH partial modifications—something I've desired
> in CouchDB for a while, since this thread:
> http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-00
>
> Any feedback would be appreciated.
>
> Paul
>
Cool work. Though I would argue against relying on JSONPath in the
spec, because JSONPath has no spec itself. I did a fairly similar
thing to this but instead of using paths I added operations for moving
around the JSON object. There's code for it in a Python package [1]
that I'll try and remember to move to github later tonight.
Also, I would remove all wording about HTTP from the specification.
Just because CouchDB might use the HTTP PATCH verb to apply JSON diffs
doesn't mean the diff format should be aware that HTTP even exists.
That's be like saying that unified diff's are only valid when applied
over email or something.
[1] http://pypi.python.org/pypi/jsontools/0.1