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

[Sam Johnston <[e-mail]>]

On Fri, Dec 30, 2011 at 11:41 AM, Julian Reschke <[e-mail]>wrote:

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


For a patch format, agreed — so include it (as optional). In saying "it's
also not always
possible to define what goes in a document" I mean that as a user you may
have needs not considered by the document format authors. For example, you
may want to include a link to an issue tracking system — do you extend the
format or use a Link: header? I know what I'd do.

Another more generic example I like to use is a photo hosting site — while
photo formats (e.g. JPEG) now carry metadata channels (e.g. EXIF) I'd
rather be able to glean semantic information (e.g. links, attributes,
categories) from the headers than having to retrieve and parse the resource
for an embedded resource that itself has to be parsed!

Anyway this is getting off-topic — in this case I think there's
justification for native in-band support, possibly with link references too.


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


IMO a patch format (c.f. diff) should be "must-understand", even if some
parameters are made optional.


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


That's a contrived interpretation — is it something we want to support? I'd
rather a PATCH throw a 4xx error if a resource didn't exist... an empty PUT
would create a resource that could then be PATCHed, no?


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

Ah, that makes a lot more sense now, though it does sound like a premature
optimisation.

Sam