« REST Layers and REST Applications | Main | Describing Resources, the Web Way »

Saturday, March 17, 2012

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Benjamin Carlyle

PATCH has actually been around for a while[1] :)

[1] http://tools.ietf.org/html/rfc2068#section-19.6.1.1

dret

@benjamin, thanks for the pointer. regardless of when it appeared, that doesn't change the fact that strictly speaking the current AtomPub spec does not allow PATCH, right? the main reason for writing this post was to figure out how we can PATCH-enable AtomPub, and i guess there are at least the variants that i have proposed, and maybe more.

Prathe

Thanks for bringing this.

Would 2. and 3. be OK to use right now? Or is it a proposition that would first need to make part of the protocol before using it?

What do you think would be best to use now for a client that use PUT be could be updated to use PATCH when available?

dret

thanks @prathe for your comment. 2 and 3 would need some form of consensus, in the form of registered/well-known link relations or a well-known profile (and the 'profile' link relation type itself is not yet standardized). cooperating communities could start using approaches 2 and 3 right away, but for it to become an expectation than could be supported in general-purpose atompub clients, there would need to be consensus around the link relations or the profile URI.

it might be most elegant to just rely on 'edit' and OPTIONS, and 1 suggests that it might be safe to just use this right now, but i think for clients to be aware of this (use OPTIONS on the 'edit' link to find out about PUT and/or PATCH support), it should be added to atompub itself. then you would end up with 'old' atompub (just PUT) and 'new' atompub' (use OPTIONS), but old clients could still happily live with new services, only that they would never discover the ability to use PATCH instead of PUT.

The comments to this entry are closed.

Flickr