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. regards, Lars 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 >
