hi, On 7/31/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi Toby, > > On Jul 31, 2008, at 21:01 , Tobias Bocanegra 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. > > > > > yes, but only if the addressing does not change in respect if the > > resource is present or not. > > > > David's original point was that cutting off extensions might be necessary > to preserve the idempotency of the POST request. I have shown that it is not > necessary. > > > > > > > > > > > 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) > > > > > > > no, the URL (and only the url) locates the representation of the > > resource, which is in most cases the same, of course. > > > > URL (Uniform Resource Locator) locate resources in a uniform way. Resources > and representations are not the same or identical, as they describe > different concepts. Even if there is only one representation of the resource > (which is almost never the case with Sling where we have a txt and a json > representation for every resource). > > > > no matter what > > headers are set, if i request a .html, i want a HTML document (or i > > should always get the same, irrespective of the headers). > > > > Not necessarily. The HTTP spec mentions headers explicitly for content > negotiation > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html) > and there might be enough cases where a resource (!) happens to have a name > ending with .html without implying that it is actually HTML. The server > selects the representation that is being sent and the server determines how > to value headers or not. content negotiation is certainly an interesting capability, but IMO poses a lot of problems. for example, i don't want another representation of a document (for the same url) just because my browser locale is different. if the urls are not stable, the documents can't be cached, which is bad.
> > it's very logical, that a foo.html and foo.pdf are different > > representations of the resource foo. > > > > Only if you forbid having foo.pdf and foo.html as two different resources > in the same path. In that case you would have foo.pdf.html and foo.html.pdf > and foo.html.html and foo.pdf.pdf. which i would find very confusing. > > so actually, if i want to change > > representation independent properties, i need to post to /foo, if i > > want to change PDF representation properties, e.g.. a watermark, i > > post to foo.pdf. > > > > If your representation has distinct properties that can be changed > individually, you do not have a representation, you have another resource. > If you want to upload a new thumbnail, you should PUT it to the appropriate > resource and indicate the content type accordingly. > > > > however, this does not help us here. > > > > i suggest to leave the resolution the way it is, > > > > I have read this before, but I still do not understand why. You mention not > a single real use case that would be broken through my proposal. as i said, i fear problems if non-existent and existent resources are treated differently. > > and you need to find > > a workaround for your upload-a-css-file problem > > > > Thank you very much for your proposal. I did look for workarounds and found > them cumbersome and inconsistent with the intended RESTful nature of Sling. > Which was the reason why I proposed to fix it. > > > > (which should be done > > via webdav anyways :-) > > > > Unfortunately I have no WebDAV in my browser and it is quite hard to > convince the browser to PUT the contents of a textarea to an URL. > Furthermore, the Sling way of expressing a PUT to a non-existing resource > with a POST does not work, precisely because the POST servlet does something > the WebDAV servlet will never do: it ignores the resource location the > client specifies and tries to apply its own rules of finding out what's best > for me. If this is the case, we should perhaps change the behavior of the > WebDAV servlet accordingly to make it a bit less surprising. > > regards, > > Lars > > > > > > > > > regards, toby > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
