On Thu, Feb 24, 2011 at 5:08 PM, Bertrand Delacretaz <[email protected]> wrote: > On Thu, Feb 24, 2011 at 5:00 PM, Markus Joschko > <[email protected]> wrote: >> Bertrand: >>> I think redirects in POST are no problem with non-browser clients, as >>> per http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 >> >> Mhm, I understand that the opposite way: >> >> "The action required MAY be carried out by the user agent without >> interaction with the user if and only if the method used in the second >> request is GET or HEAD" > > In your case, IIUC there's no human user, so the client system could > make that decision, IMO.
That's true. Still I would like to make it as easy as possible to use the API and would prefer direct POSTs instead of having to deal with a redirect. The "speaking" URL is nothing the external system cares about. >> >>> Note that I'm not against expanding the resource resolver - but there >>> might be a simpler and more RESTful way. >> >> The problem we face currently is simple: We have information that will >> be moved frequently in a tree but have the requirement that other >> systems need to access that information directly (without doing a >> search). >> Is a URL like http://x.y.z/UUID/1234.html less REST? For a human it is >> not as descriptive but for a system that doesn't matter.... > > Right, "more RESTful" was not really what I had in mind - it's more > that http might provide everything needed to solve your problem with > little changes on the Sling side. > > Anyway, access by UUID can be useful as well, so both options are > probably worth exploring. And in our case not only the UUID but also an arbitrary systemId which is not managed by the JCR itself. That brings us back to the original question whether it is possible to handle the JCRNodeResource less restrictive as it could be used by all kinds of alternative JCR based Resolvers. Regards, Markus
