Gabor Szokoli wrote:
> On Fri, Feb 29, 2008 at 5:55 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> On Feb 29, 2008, at 5:40 PM, Marc Hadley wrote:
>>
>> You can use UriInfo.getQueryParameters instead of lots of @QueryParam
>> annotated parameters.
>
> Yay! Thanks!
>
> Jersey does everything I want, but somehow I'm unable to find it out
> myself from the documentation...
>
Sorry :-( we need a big picture arch document, linking to JavaDoc... the
thing is i am reluctant to start writing such documentation until the
spec settles down, otherwise it becomes out of date and more work to
maintain it.
>> I would really like to work out how to integrate Jersey with Wicket.
>>
>
> We use wicket extensively, but I'm just getting my feet wet with jersey.
> Might take a while before I can contribute.
OK. Any views/ideas would be greatly appreciated.
> The two world views seem totally opposing at first though:
> REST is about stateless resources, wicket is about automated widget
> state in the HTTPSession.
Yes, this is very common from a Web-based UI perspective. It is possible
to program Jersey resources using servlet HTTP session state, or say a
Wicket session life-cycle (if it exists?), as one can write a
ResourceProvider and create a specific annotation using that to annotate
resource classes.
I wonder with the advent of standardized browser-side storage APIs
whether an application-state in the message based approach will catch on
for such frameworks. You can sort of do it with cookies as long as they
are not opaque identifiers.
> It is possible to use session state in REST and stateless pages in
> wicket, so it's not totally hopeless :-)
>
Yes, it breaks the Stateless Constraint of the REST style:
"Like most architectural choices, the stateless constraint reflects a
design trade-off"
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
In general the above is a great read for the advantages and trade-offs.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109