It looks like this would require one minor change to the Stripes core
which should probably happen anyway. Currently the DispatcherServlet
overrides doPost() and doGet(). doGet() simply calls doPost(). If
service() was overridden instead it would handle any HTTP method instead
of just GETs and POSTs. Then it would be easy to add REST support in the
form of an interceptor without touching the core of Stripes.
That's one of my favorite things about Stripes - simple clean
extensibility without having to fight the framework. If you want to use
REST just add a plugin and do a few annotations and you're all set! If
you don't want to use REST, don't add the plugin and Stripes will
function exactly like you're used to.
Just because I don't use REST now shouldn't affect someone else's
ability to use it and if I want to try it out in the future it would be
nice to have a simple plugin that enabled it.
Aaron
Will Hartung wrote:
On Jul 9, 2008, at 7:43 AM, VANKEISBELCK Remi wrote:
You're kidding ? I've posted a full email about this ! And you'll note
that nobody yet answered the magic question : what's the purpose ?
Hi Remi! Welcome back, you've been missed, or you owe somebody money
-- anyway, there's always that "Where's Remi" floating around.
It's the crack of dawn over here in the Wild Wild West, we like our
Sun a little later than y'all.
Here's the deal, I'm not going to "sell you" on REST and its merits,
as I may as well be trying to sell you on why Pagan Rituals suit some
better than others for their spiritual needs, by email...across
language and cultural barriers. No. Not going to happen.
Simply accept that the REST architecture and advocates represent a
philisophical approach to application design.
A core tenet to supporting REST, however, is full support and
exposure of the HTTP protocol, with all its headers, codes, and verbs/
methods.
Right now, Stripes handles much of the Hard Work of working with HTTP
requests. Specifically binding. Upon that it adds event dispatch
which makes writing logic for a classic web UI application easier.
Finally, we get nice benefits through its validations and such.
That means that if someone wanted to create an application in the
REST style, they, too, could leverage all of those benefits that
Stripes provides, as they're necessary even for a REST application.
It is just HTTP, after all.
However, because Stripes is focused on a Web UI applications, which
relies on the browser being the client, Stripes has a limited view of
the HTTP protocol, limited to effectively just that small part of the
protocol supported by the classic web browser.
Now, of course, being that it's built on top of the Servlet spec, a
developer always has access to the raw HTTP request, and can do
anything he wants. So, really what work is to be done?
But you could argue the same thing about Stripes. Servlets give us
the raw parameters for us, we don't have to parse HTTP requests or
anything, so what value does Stripes have? Obviously quite a bit,
it's a stupid question.
There are 2 major forces in the Web Service arena today. SOAP and
everyone else. "Everyone else" includes ad hoc web service, screen
scraping, XML-RPC, and REST.
SOAP is the 800 pound guerilla, which is its blessing and curse. I
think the standard documents alone weigh 800 lbs.
I'm not here to advocate or condemn SOAP. But I mention it because
many see the REST architectural style as a different, "lightweight"
path of doing web services as compared to SOAP. Yet, REST is a bit
more formal than Ad Hoc web services.
I also feel that, long term, the browser as an application platform
is going to get "thicker and thicker". I believe that more and more
applications will be simply running within the browser, and use some
kind of web service to talk to the back end systems.
When you can use software tools to help make those web service calls,
SOAP has a leg up. Huge application framework reduce that 800lbs of
documentation in to a simple annotation.
However, when you have to hand code those web services, folks fall
back to something simpler. There are few folks that like crafting
SOAP envelopes and messages by hand. And REST as an application idiom
and style happens to fit that role of a "simpler web service" quite
well. You get a simple web service, yet you get some overall
structure and, ideally, implied compatibility with other REST style
web services.
So, I can see how many folks will be writing fatter browser
applications, and want to talk to a REST style back end application.
I see no reason why Stripes can not fill that role as a back end
framework quite well.
As I said, I haven't seen an Action framework that handles both REST
and the classic action problems we have as web UI application
developers. And I think there is value in having a single framework
that can do both.
For example, Nick mentioned they're using Jersey. I assume they're
bundling it with Stripes. So, now he has to learn and juggle both
frameworks in order to provide services to his application. For
example, if he has a web form, he may front that with Stripes,
whereas his REST version is fronted with Jersey. Ideally, the code is
refactored out and facaded by each framework. Wouldn't it be nice to
not have to do that.
As I outlined, I think that making Stripes a better REST citizen is a
minor uplift to what it already does, that's what makes this an even
better idea. If all we have to do is add an annotation, play a bit
with dispatch and add some utility classes, and we get a REST
friendly framework with all of the current Stripes functionality "for
free"? Seems like a powerful combination to me.
Also, it's a testament to the appeal of a REST style architecture
that something like Stripes could be readily enhanced to better
support it. It uses what "we already know", and just adds a few rules
and style points.
If I proposed supporting SOAP to Stripes, there'd be a mob outside my
door with torches and pitchforks! And if I were crazy enough to
propose adding SOAP to Stripes, I would have opened that door because
I'd deserve whatever the mob dealt upon me. What an insane idea.
Finally, as I also mentioned, the hope is that this can all be done
in Stripes Stuff without have to tweak Stripes core at all. I'm 100%
in to keep Stripes simple, and not adding extra cruft in to it. But I
do think that since Stripes lingua franca is HTTP, that it could
benefit by speaking it a little bit better than it does now.
I solicited feedback here to try and iron out thoughts and details
about how this might be pulled off, because, as everyone knows, I'm
the last person to talk to about how Stripes works. I'll advocate it
from the roof tops, but I use 1% of the framework and just live
happily in my little corner. So, Others know better about how perhaps
this kind of upgrade can be pulled off than me.
Regards,
Will Hartung
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
