Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation

[Sam Johnston <[e-mail]>]

On Fri, Dec 30, 2011 at 6:24 AM, Paul C. Bryan <[e-mail]>wrote:

> **
>
> First, I think commit messages should probably be out of scope for JSON
> Patch specifically. That said, we should allow the ability to build on the
> specified format, allowing for extensions, including additional (more
> domain-specific) operations.
>

Maybe so, but saying what you're doing when manipulating an object is often
a good idea.


>  I'm generally against the idea of using out-of-band metadata such as
> header fields in an HTTP request, mostly because it ties metadata to the
> transfer protocol rather (what I believe rightly should be tied to the
> document).
>

The distinction between data and metadata isn't always clear — to me a
document detailing manipulations could just as easily be separated from the
description of it (or it could be redundant — with the headers reflecting
data contained within the document). It's also not always possible to
define what goes in a document, so if you have metadata (like commit
messages) then I'd argue you should use HTTP's existing metadata channel
rather than an "envelope" like SOAP (or JSON).


> I'm interested in feedback on the possibility that I add text stating that
> if an operation cannot be determined for a given patch object, then an
> implementation should ignore it. Thoughts?
>

To me this sounds dangerous — add versioning and if there's sufficient
demand for extensions then just include them in a future version?

>  2) The ability to *copy* (not *move*) objects around.
>
> This is another example of something trivial for the patch implementation
> to perform, so I'm inclined to add it to the next draft.
>

This begs the question as to whether PATCH should be creating new
resources; the scope of PATCH ("to modify an existing HTTP resource") is
fairly clear on this IMO. Furthermore, MOVE and COPY verbs are useful for
other applications (e.g. cloud APIs) so promoting them from WebDAV, sans
XML dependency, would likely be useful for other applications.

Sam