Hi Jerome,
Jerome Louvel wrote:
Hi Bruno,
1) Uniform interface
[...]
The bottom line is that HTTP semantics are the reference when defining or
interpreting the Restlet core API properties or behavior.
HTTP being the de-facto REST protocol reference, it is indeed the right
choice for Restlet. Having the second layer is certainly useful, but I
haven't had to use it so far, and I'm hoping not to have to. I think
this thread on the REST-discuss list is quite useful on this topic:
http://comments.gmane.org/gmane.comp.web.services.rest/7943
The only extension I may have thought could be useful would be something
like "SEARCH", which would be similar to GET (no side-effects,
idempotent and proxy-able) but with a body. I'm still against a body in
GET, since this would break the ability to discover resources. This
"SEARCH" would in fact just be an implementation detail to solve the
problem of encoding a large XML-based expression in the URI. I can't
really think of a good theoretical reason for it (in fact, in theory, I
quite like the idea of modelling a given search as a resource in its own
right, however long that URI may be), and if both implementations of
client and server can handle potentially very long URIs, then there's no
reason for it. (I haven't tested the limits of Restlet in this matter.)
2) PUT with no entity
I have yet to come across a solid use case that requires this, but I'm not
fundamentally opposed to allow this if it is really useful or if the current
behavior is really blocking.
I must admit the cases I was talking about were purely hypothetical, I
was just surprised by this constraint.
The use case you mention about content negotiation (being able to clear just
one specific variant) is not allowed by REST (per Roy T. Fielding). I fall into
the same trap at some point in the past. When you PUT a representation you
change the *whole* state of your resource. Unless you treat your
representations as identifiable resources, you can't update or delete a
specific resource variant. If you think deeply about it that should make sense.
If you search in the REST-Discuss list you will find related threads.
I'm already convinced!
Regarding status code 204, by interpretation of the spec is that it is expected after a
POST or PUT method or other, but not after a GET: "The server has fulfilled the
request but does not need to return an entity-body"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.5
The list use case can be supported by defining a list item content type, for example an XML representation
"<item/>" instead of "<item>1234</item>".
Anyway, this is my current opinion and I'm open to changing it if necessary.
This is a good question to ask to the REST-Discuss list or to the HTTP WG
experts. Maybe there are existing discussions? Any pointer?
Yes, I don't actually feel strongly in favour of allowing PUT requests
with an empty body. I agree with your arguments. Perhaps the original
poster on this thread could elaborate on his use-case or raise the
question on the REST-discuss list.
Bruno.
-----Message d'origine-----
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : mardi 27 mai 2008 11:17
À : discuss@restlet.tigris.org
Objet : Re: PUT and entity
Hi,
Steve Loughran wrote:
On Tue, May 27, 2008 at 8:13 AM, Stephan Koops <[EMAIL PROTECTED]> wrote:
Hi,
also if the question do not come from me: IMO a generic framework should not
forbid things, that are not explicit forbidden. So, if it is vague, if it is
forbidden or not, then it should be possible to send an request with no
entity (IMO). A possible solution is to allow to switch this forbiddance on
or off.
That's an interesting point. Although Restlet does try and hide you
from the fact that HTTP is underneath, it is still there and ought to
be embraced. At the same time though, theres that XMPP transport, and
it doesnt have to contain the same set of assumptions.
I don't know XMPP in details, but does it have the same uniform
interface (or at least, is there a one-to-one mapping of XMPP and HTTP
sets of verbs)? Abstracting away the underlying protocol from the REST
framework is a good idea, but I guess there's a point where the
representations have to nail down which transfer protocol can be used,
or at least what the uniform interface is and how it maps to the
transfer protocol.
Restlet makes the assumption that this uniform interface consists of
"get", "accept", "store" and "delete", which maps fairly well to the
HTTP verbs and this works fine, but I suppose one could have a RESTful
system where the uniform interface differs slightly from this.
Even so, PUT is taken to mean 'put something there to create a new
resource', so if you dont have a body, what are you creating? A URL
with nothing behind it?
I think PUT with an empty body should be allowed. The cases where it
could be used may be unusual, but I don't think banning it is right.
Firstly, taking into account content-type negotiation, there may be
situations where the client would want to blank a particular
representation for the same resource, without deleting the resource itself.
Secondly, HTTP has a "204: No Content" response code. A resource on
which a GET returns this status code could have been set up with an
empty representation via PUT beforehand.
Finally, here is a possible example: a list that allows 'null' elements.
Suppose there is a list identified by 'http://.../list', which contains
a set of resources identified by 'http://.../list/1' to
'http://.../list/10'. If this list can have 'null' elements (10 slots,
some of which may be empty but still exist), a client could empty
element 'http://.../list/10' by sending an empty PUT request. In
contrast, DELETE 'http://.../list/10' would shorten the list, without
making it possible to set the value of 'http://.../list/10' afterwards.
In this case, DELETE could also have the side-effect of deleting the
link from the list resource 'http://.../list' (making that 10th entry
unreachable from a client discovering the list through its entry point),
whereas an empty PUT would have kept the link (thus keeping that 10th
entry reachable).
Best wishes,
Bruno.
