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

[Julian Reschke <[e-mail]>]

On 2011-12-30 11:09, Sam Johnston wrote:
> On Fri, Dec 30, 2011 at 6:24 AM, Paul C. Bryan <[e-mail]
> <mailto:[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 think both are valid points of view :-)

As a data point: when I submit a hg patch to Mozilla, I specify the 
commit message in-band. I think that's a very useful thing to have.

>     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?

So yes, we need to state whether the format follows the 
"must-understand" or "must-ignore" pattern. Or allow optional parameters 
(such as a commit message) to be marked as such.

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

Of course that depends on how you define the lifetime of a resource. 
Does a resource which currently doesn't have a retrievable 
representation "exist"?

Technically, PATCH can work for creating an initial mapping as well.

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

I agree that COPY and MOVE are good things if you indeed want to COPY or 
MOVE full resources (or hierarchies). I never understood the resistance 
to COPY and MOVE in the AtomPub community.

That being said: the proposal is for copying JSON object members, not 
HTTP resources; so this is an operation that can't be done with COPY 
unless you have HTTP mappings for each of the JSON object members (and 
even then you wouldn't be able to express them as part of a bigger PATCH 
operation).

Best regards, Julian