Re: Where do we currently stand with our position on PATCH?

hello all.

On 2014-01-13, 13:58 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>>Once a patch format is agreed upon we will be able to make PATCH a
>>mandatory feature of LDP.
>I would not jump to "mandatory" in the sense of "MUST support PATCH".
>Container semantics are perfectly sensible and useful whether or not
>PATCH is supported.  A whole heck of a lot of clients use similar ones
>(*cough* Atom *cough*) in read-only
> or append-only mode (via methods other than PATCH) very happily.  Just
>knowing how to find and iterate over container members in a general
>fashion has benefits.

in REST, there's no *must support* in this sense. you define the
hypermedia controls, and if they're there, a client can use them, and if
they're not, it can't. it makes sense to define those controls, so that
there's a well-defined way to discover them, but then it's up to the
server and its capabilities and the specific capabilities of the resource
and the authorization of the client to determine whether these controls
are made available or not.

>We have discussed the "If (iff) you support PATCH, then you MUST support
>format X", and that also is perfectly sensible and useful as a way to
>establish a baseline for wide interop.

again, there usually is no *must support* in REST in this way. you can
look at this in the same way as HTML's images. nowhere does HTML say which
image media types MUST be used. it simply defines the hypermedia control
(<img/>), and then uses loose coupling to determine the media type at
runtime. this allowed good things such as PNG to happen. PATCH defines
Accept-Patch, so a server can expose its PATCH format support when serving
a response containing controls for PATCHing, and then it's a runtime thing
to decide whether there's a match between the PATCH formats supported by
the server, and those supported by the client.

cheers,

dret.

Received on Tuesday, 14 January 2014 08:16:26 UTC