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.
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.
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.
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
