(Changed subject line to reflect drift) Adam and I were discussing this at our
shop yesterday ...
One of the issues I have seen bite Restlet newbies is that Form is the
idiomatic path to access query string parameters and such, but
getEntityAsForm() consumes the request. If someone calls getEntityAsForm() in,
say, a Guard, to look for an authentication token on the URI, a downstream
Restlet trying to get the representation will fail and this results in
puzzlement.
Now, it is not good REST to mix a function call paradigm with representational
state transfer in the same call; while it is a common Web practice to glue
query string parameters onto an unrelated representation as a signalling
mechanism, this is not RESTful, and it is probably good that the NRE
discourages this. Notionally, a single HTTP operation transacts a single
representation, and that representation should represent a single thing.
But I think it would be perfectly fine, however, if getEntityAsForm() and
getEntityAsDom() could be called repeatedly, and subsequent calls against the
same Entity would simply retrieve a reference to the Form or DomRepresentation
created in the prior call. This neither encourages sloppy REST nor breaks
scalability. The relevant in-memory objects have already been created and will
go away when the request completes. While the underlying representation types
(e.g. StreamRepresentation or SaxRepresentation) are indeed transient, the Form
and DomRepresentation actually represent a completed in-memory parse of the
underlying transient representation ... and need not be transient themselves.
So this would work:
Form form1 = request.getEntityAsForm();
String f1s = form1.getFirstValue("foo");
Form form2 = request.getEntityAsForm(); // just returns another reference to
form1
String f2s = form2.getFirstValue("foo"); // should not throw an exception
While you might no longer be able to access the original entity or a
/different/ Representation after calling one of these methods, there's no
reason that a number of Restlets in the same chain, needing to operate on a
Form or DomRepresentation, actually need to implement their own private caching
mechanism. We already have some fairly long chains of Restlets using components
that are supposed to be pluggable and interoperable; the less they have to be
aware of each other the better.
I haven't looked into a patch yet, but I can't imagine it would be tragically
complex.
Thoughts?
----- Original Message -----
From: "Thierry Boileau" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, August 28, 2007 2:59:36 AM (GMT-0500) America/New_York
Subject: Re: Custom gaurds
Hello Alan,
well, you're right, Jerome could have define Representations with some caching
system allowing to get content anytime we want. I think that Jerome had made
the design choice that :
- gives you the lighter and cheaper way to use transient representations, when
you read them once (which is a basic but probably the most frequent case, I
think)
- let you free to simply and transparently convert a transient representation
to a StringRepresentation (or any kind of self defined representations) for
example in case you want to read it several times which means unavoidably that
the content is "stored" in memory, in a file, etc.
best regards,
Thierry Boileau
On 8/27/07, Alan < [EMAIL PROTECTED] > wrote:
Thierry Boileau <thboileau <at> gmail.com > writes:
>
> Hi,
>
> This "limitation" concerns the following representation classes (and
> descendants included in the Restlet API and NRE) :
>
Ok, for my clarification:
the "limitation" is due to the implementation of the NRE library,
not a limitation of the http model?
In theory, an implementation could do something like cache the initial input
source to make subsequent calls to getEntityAsFoo work.
Is there a reason for this?
Looking at the source I saw that it is possibly due to the fact data is read
off a stream of unknown length and caching request data may be prohibitively
expensive?
By the time the server is processing the request is the client
pipe closed? (I guess I'm thinking about something like continuations).
I'm just curious, I have no plans to offer another implementation :)
I suppose I'll need to rethink my implementation if I wish to make restlets
behave in an filter/guard agnostic manner.
By the way, this is a nice paradigm, I much prefer it over servlets.
thanks.
