On 7/30/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi, > we are not violating the idempotency of the PUT (disguised as a POST) > > 1. POST /foo.bar.html (foo=bar) > 2. GET /foo.bar.html > 3. POST /foo.bar.html (foo=bar) > 4. GET /foo.bar.html > > If request 1 and 3 are identical, responses 2 and 4 will be identical as > well. does not compute :-)
as far as i understood REST, the url always addresses a representation of a resource. so when you GET a /foo.html you get for example the HTML representation of the resource /foo. if you post to /foo.html, you want to update the HTML representation of the resource /foo. and i think here is the problem, since .css (or .pdf, ...) is treated the same way. i your example, if you want to 'upload' the /foo.css, then in this case, the resource and the representation URL are the same: /foo.css. but i don't know how to discover that in a smart way. maybe because there is a file parameter pointing to "." ? regards, toby > On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > > > hi guys, > > > > i think it is dangerous if we have a different behavior on a POST (that > > originally should have been a PUT anyway, but due to browser > > limitations...) > > based on the existence of a node. I think that would violate the idempotent > > behavior that we had on the "PUT oriented" operations in the > > slingpostservlet. > > > > regards, > > david > > > > On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra > > <[EMAIL PROTECTED]> wrote: > > > On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > >> Hi, > > >> > > >> all taking this to the list for discussion because Lars it making some > > >> important points. > > >> > > >> Lars Trieloff (JIRA) schrieb: > > >> > > >> > If you could decide for a way of fixing the NPE, I would be glad > > >> > > > >> > to have a working workaround. (and close this bug) However I still > > >> > think it is quite easy to find out which case the servlet is dealing > > >> > with. As the user is free to specify the action of the form, he can > > >> > post to /some/sample if he wants no dot and /some/sample.html if he > > >> > wants a dot. > > >> > > >> > > > >> > Speaking more broadly we are increasingly introducing "tricks", > > >> > > > >> > special cases and magic post parameters to deal with a very specific > > >> > use case "most of the times in a CMS or such" while ignoring the > > needs > > >> > of other use cases like DAM, Blog, Wiki, social networking, forum, > > >> > online shop, podcast, file sharing and other content-centric web > > >> > applications. Having a RESTful web application framework implies in > > >> > my opinion to respect concepts like Resource, Representation, URI > > >> > and to avoid RPC-like interaction if not necessary. > > >> > > >> I agree and thinking about it the SlingPostServlet is more about > > modifying > > >> (create, update, delete) content and less about content representation. > > As > > >> such the URL fired at the SlingPostServlet should probably be more > > treated > > >> as the actual path than it is today. > > >> > > >> The actual code, which does this is buried in the > > >> ModifyOperation.getItemPath method, which tries to locate the item to > > work > > >> on from the resource. For an existing resource, there is nothing much to > > be > > >> done, as we have the item through the resource. > > >> > > >> For a non-existing resource, the resource path, contains the full path > > from > > >> the URL (actually it is ServletRequest.getPathInfo()) including anything > > >> which might be interpreted as selectors and extensions and even suffix. > > The > > >> idea of this was, that the SlingPostServlet might redirect to this URL > > after > > >> the update. > > >> > > >> Now, in the meantime we have applied various changes to the > > >> SlingPostServlet, which influence the creation of the name of a node to > > >> create: > > >> > > >> * :name and :nameHint to handle how names are generated > > >> in the case of Slash-Star request (trailing / or /*) > > >> * :redirect to indicate whether to redirect to the modified > > >> or created node after the request. > > >> > > >> Taking all this into account, I come to agree with Lars, that the > > >> SlingPostSerlvet should treat the resource path of a non-existing > > resource > > >> (to be created) as is without modification. > > > i don't think that this is a good idea. otherwise you would need to > > > know on the client if a resource already exists or not. ii find it > > > very dangerous if the resolution is not symmetric. > > > > > > IMO, with the extension, you choose the type of response you want. eg, > > > with .json you get a json response, with .html you get a html > > > response. etc... > > > > > >> We still have to deal with the / and /* suffixes, but we do not cut off > > any > > >> extensions any more from the path. > > >> > > >> In the case of a redirect, the :redirect parameter could just be set > > with > > >> *.selectors.ext to redirect to the newly create resource with selectors > > and > > >> extensions, where the SlingPostServlet replaces "*" with the actual > > location > > >> URL of it. > > > > > > regards, toby > > > > > > > > > > > -- > > Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro > > >
