Hi all,
The refactoring based on this discussion is done in SVN trunk. See this
issue for few more details:
http://restlet.tigris.org/issues/show_bug.cgi?id=361
I've also updated the 1.1 snapshot at:
http://www.restlet.org/downloads/1.1/current.zip
Best,
Jerome
Hi Sumit,
So what's the difference between a Handler and a Finder?
The Finder class still has the same role. It can find and instantiate
target handlers. As Resource is a subclass of Handler, it can also
instantiate target resources like today.
The flow of the request would go through the
Jerome Louvel contact at noelios.com writes:
Hi all,
Thanks for the quality of the feed-back. I feel like I'm now grasping all
aspects of the problem and can propose a solution:
1) Split the Resource class into an abstract Handler class and a Resource
subclass
Hi Jerome,
What is the
Hi Sean,
What is the motivation of the Handler class? I have no
problem with it, I just want to understand. Is it merely to be explicit
about
lower level API and higher level, or is there more to it?
Exactly, the goal is to clarify the separation between the lower API and
higher one.
The
Sean Landis sean.landis at gmail.com writes:
Jerome Louvel contact at noelios.com writes:
Hi all,
Thanks for the quality of the feed-back. I feel like I'm now grasping all
aspects of the problem and can propose a solution:
1) Split the Resource class into an abstract Handler class
: dimanche 14 octobre 2007 01:25
À : discuss@restlet.tigris.org
Objet : Re: HEAD not well supported?
Tim Peierls wrote:
There's a false parallel here that I don't think should be
encouraged by
providing parallel names. getRepresentation takes a Variant
argument,
handleGet does not; post
Tim Peierls wrote:
There's a false parallel here that I don't think should be encouraged by
providing parallel names. getRepresentation takes a Variant argument,
handleGet does not; post takes a Representation argument, handlePost
does not. If anything, I'd argue for names that were *less*
Tim Peierls tim at peierls.net writes:
There's a false parallel here that I don't think should be encouraged by
providing parallel names. getRepresentation takes a Variant argument, handleGet
does not; post takes a Representation argument, handlePost does not. If
anything, I'd argue for names
I have always been a bit unsure of which methods to
override for the different verbs/methods, always
considering it a bit of a nuisance and a potential
put-off for new adopters (I'm carrying on about the
potential problems to new restlet implementors, but
it's only because I believe it's one of
Hi all,
Thanks for sharing your experience. This is very valuable feed-back
and I want to address these issues to this core class in release 1.1
if possible/necessary.
To try to clarify, I was initially hesitant to call
getRepresentation(Variant) just get(Variant) due to potential
confusion with
Hi Sean,
I think *Representation is problematic: headRepresentation()?
I understand your
concerns with get(Variant), getVariant(). A colleague of mine
pointed out that
conceptually, merely using post(), get(), etc., is like
encroaching on a global
name space. He suggested (and I'm
Jerome Louvel contact at noelios.com writes:
...
It could also clarify things by renaming post(Rep.) to
postRepresentation(Rep.) to be more consistent with
getRepresentation(Variant) namine and to reduce the confusion with
lower-level Uniform handle* methods.
What do you think? What is
On 10/11/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Sean,
I think *Representation is problematic: headRepresentation()?
I understand your
concerns with get(Variant), getVariant(). A colleague of mine
pointed out that
conceptually, merely using post(), get(), etc., is like
Erik Hetzner erik.hetzner at ucop.edu writes:
At Mon, 8 Oct 2007 17:35:00 + (UTC),
Sean Landis sean.landis at gmail.com wrote:
[...deleted...]
I'd say that Restlet meets the requirements of the spec and that's
good. Although I still think it would be better to leverage Uniform
On 10/10/07, Sean Landis [EMAIL PROTECTED] wrote:
[...]
We have about a dozen people writing web services using Restlet. Although
head is confusing, I'd say we experience more confusion over the fact
that GET is a 'special case'. That is, there's no get(), but instead you
must use
At Mon, 8 Oct 2007 17:35:00 + (UTC),
Sean Landis [EMAIL PROTECTED] wrote:
Regarding my previous comments regarding a test using curl; it appears curl
is hung up on the fact that content length has a value and there is no
entity. I did determine that Restlet does remove the content. Sorry
Jerome Louvel contact at noelios.com writes:
Hi all,
I'm a bit late in the discussion it seems :)
Let me try to explain how the support for HEAD was designed in Restlet.
Following the definition of HEAD from the HTTP spec [1], I got convinced
that HEAD was only a special GET and
regards,
Jerome
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis
Envoyé : vendredi 5 octobre 2007 21:43
À : discuss@restlet.tigris.org
Objet : Re: HEAD not well supported
At Sat, 6 Oct 2007 18:40:36 +0200,
Jerome Louvel [EMAIL PROTECTED] wrote:
Hi all,
I'm a bit late in the discussion it seems :)
Let me try to explain how the support for HEAD was designed in Restlet.
Following the definition of HEAD from the HTTP spec [1], I got convinced
that HEAD was only
In Summary...
It sounds like folks are in agreement that HEAD is not properly supported but
I haven't heard from Jerome or Thierry, etc. What do you guys think?
So is HEAD too obscure to garner any interest?
Sean
John D. Mitchell jdmitchell at gmail.com writes:
On 10/3/07, Sean Landis sean.landis at gmail.com wrote:
So is HEAD too obscure to garner any interest?
I think it's probably a good default to have allowHead == true and
default to having handleHead() call handleGet() but head should be
Sean,
I agree that HEAD should be supported.
Just for the sake of discussion, however, I personally don't find HEAD
all that interesting in comparison with Conditional GETs.
I mean, when does the client ever just want to see if a resource has
changed (or exists) without actually retrieving
-
From: Adam Taft [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Wednesday, October 3, 2007 4:07:22 PM (GMT-0500) America/New_York
Subject: Re: HEAD not well supported?
Sean,
I agree that HEAD should be supported.
Just for the sake of discussion, however, I personally don't find HEAD
Rob Heittman wrote:
The main reason I've used it is to fetch content-length and make any
necessary provisions (check storage space, warn user, etc.) on the
client side before fetching the representation.
In this case you definitely don't want the whole GET response coming
at ya.
Ya, OK.
At Mon, 1 Oct 2007 19:28:09 + (UTC),
Sean Landis [EMAIL PROTECTED] wrote:
I was implementing HEAD on a resource and couldn't figure out how to do it
so I looked at the source for Resource.handleHead() and was surprised to
see it calls handleGet(). My understanding of HEAD is that it
Erik Hetzner erik.hetzner at ucop.edu writes:
I don’t understand what the issue is here? Can you not override
handleHead?
Yes you could but there's already a programming model for dealing with HTTP
methods. One could argue handle*() methods could be final for example. Why
exclude HEAD from
Erik Hetzner erik.hetzner at ucop.edu writes:
Are you saying there's some place in Restlet where the entity is striped
out in the case of HEAD? You might be right, although I didn't see it.
Regardless, that makes unreasonable assumptions about the intent for
HEAD.
I don’t know; it just
At 11:37 PM + 10/3/07, Sean Landis wrote:
Here's an interesting follow-up. I have a resource that only implements GET
and returns Ok. As the code implies, a HEAD request will do just like
GET.
When I run: curl --request head my-url
It blocks until timeout and then prints:
curl: (18)
Aron Roberts wrote:
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response.
Would this also imply that the correct HTTP Status code to be returned
from a HEAD request should be 204, corresponding in the Restlet
framework to something
At Wed, 3 Oct 2007 19:39:10 -0700,
Aron Roberts [EMAIL PROTECTED] wrote:
In the message Re: HEAD not well supported?, dated 10/3/07, Adam Taft wrote:
NO! The whole point of HEAD is to emulate a GET request, except
without returning the message body. You don't need to send 204
because
31 matches
Mail list logo
