the Atom Publishing Protocol (AtomPub) predates HTTP
PATCH, and therefore there is no way how it could explicitly allow updates to be made via HTTP
PATCH instead of
PUT. but instead of allowing any update method, both the
edit and the
edit-media link relation type hardcode the fact that updates are made by using
PUT. this means that conforming implementations have to support PUT (and maybe they can support
PATCH; supporting other methods is neither explicitly allowed nor disallowed by the spec).
one of the advantages of
PATCH is that updates can use any kind of diff format that is deemed appropriate for the application, and thus (in case or larger resources, for examples) it may be desirable to use the general patterns established by AtomPub, but to allow updates by
PATCH, maybe in addition to
PUT, or as the only allowed method for updates. but what would it take to
PATCH-enable AtomPub? there are (at least) three possible answers, and i am curious to see whether there is some community consensus for the best one.
- do nothing: maybe the interpretation that
edit-mediamention the required method allows us to
stretchthe interpretation of AtomPub a little and assume it is ok to also or only allow
PATCH? (i guess my quotation marks make it clear that i don't think this would be the proper way to do it.)
- add new links: it would be possible to define
patch-medialink relations, which would be explicitly defined to use be used with
PATCH. it would be a bit unfortunate to have two links instead of just having one edit link that could be used with
OPTIONSto learn about the available methods, but one could argue that the fault lies with AtomPub's hardcoded
PUT, and thus this has to be done to not mess with AtomPub semantics.
- create an AtomPub profile: another approach would be to allow
edit-mediaand thus allow clients to explore the available methods. this could be signaled by a profile link in the feed or entry, and clients supporting that profile would know that they could use
OPTIONS. clients not knowing this profile would simply have to deal with the fact that some
edit-medialinks might return
405 (Method Not Allowed)errors, but REST clients should be able to deal with this kind of failure scenario anyway.
any opinions or comments about these three options are highly welcome, and in particular any pointers to implementations that use AtomPub and already support
PATCH. if there is some community consensus, it would be interesting to see whether it would be strong enough to move forward with option 2 or 3 and turn it into a formal spec (and if everybody is fine with option 1, then no action is required anyway).