Wicket is all about stateful applications (though stateless stuff is
useful and is supported).
REST is all about stateless resources (though you sometimes need
stateful hacks for login/authentication).
Given these premises, I would not implement REST resources with Wicket
(well, maybe if you have just 1 or 2). If you want to be more powerful,
I would rather implement REST stuff with Spring MVC. Currently I am
using Restlets which works very well also. Jersey sounds fine as well.
Regards.
Erik.
Fabrizio Giudici wrote:
Hi there.
My application, along with the usual HTML pages generated with Wicket,
should also expose some RESTful services. These REST calls should
return documents of various types: images, movies, as well as RDF/XML
and N3 and so far.
In an architectural spike I've made, I've used Jersey (implementation
of JSR-311) and of course the two things can co-exist; so everything
works and I don't have "technical" problems to solve (at the moment).
The dilemma is architectural: I'm guessing whether getting JSR-311 in
increases complexity in a way that can be avoided. In other words,
could Wicket be able to serve the same facilities provided by JSR-311
(I mean, the subset I need)?
Actually, Wicket can serve non-HTML contents by means of
DynamicWebResource, so it seems doable. There are two specific
questions now:
1. Security. For HTML pages, protected areas shoud handle login in the
WIcket way (or what I assume is the normal Wicket way), i.e. rendering
a specific HTML login page. For other types of documents, instead, I
need HTTP authentication and perhaps in future some token-based
approach. The point is that in any case either I deny the access or I
give the resource, but I can't send back an HTML login page when the
client expects a different document type. Would I be able to handle
this with Wicket?
2. Having the same URL delivering different contents according to the
Accept header. For instance, http://foo.bar/blah should normally
render an HTML page; but if a Accept: text/n3 header is specified, a
N3 should be returned. This means that in the former case the default
Wicket workflow would be ok; in the latter, a DynamicWebResource
should be provided. I think I can solve this using JSR-311: I could
implement a super-filter that discriminates on the presence of the
Accept: header and dispatches either to the Wicket or to the Jersey
filter (of course I would implement a custom URL mount scheme so
Wicket accepts the same URL as Jersey).
Hints? I'm searching to find ASAP a reason for deciding to keep Jersey
or to get rid of it, so I can go on with the development without too
many fears of having to change something in future.
Thanks.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
