Hi Toby, On Thu, Jul 31, 2008 at 1:27 PM, Tobias Bocanegra <[EMAIL PROTECTED]>wrote:
> 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 :-) What I meant is: you can post the same request parameters (representation) as often as you like, the resource will have the same state afterwards. The POST has no side-effects and it does not work additive. So it is idempotent and can work as a replacement for a PUT. > 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. The URL locates the resource. What gets transferred is the representation. We are using extensions and selectors only due to limitations of our browsers that do not allow us to set the Accept header for GET requests (which would be the proper way of indicating what representation you can deal with). I think extensions and selectors are a neat workaround, but we should not overuse them were we do not rely on them (e.g. everywhere where we can send request headers or a request entity) > and i think here is the problem, since .css (or .pdf, ...) is treated > the same way. in 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 "." ? I think we do not need to be smart here. All we need to do is trust the client (or the developer) that she is able to correctly locate the resource. Do not use magic that could stab you in the back. regards, Lars > > 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 > > > > > >
