Hey Will, folks,
Yeah it's hectic here, but I'm still alive :)
Drifting off-topic again, but hey, it's been a while... Nervous REST
fans, please skip, unless you have an answer to the magic question.
Then I'll shut my big mouth up forever with this REST thing :-P
I fully understand your concerns Will, really. I'm amongst those who
also think the browser is turning into a Virtual Machine unfortunately
: I tend to prefer a JVM for that purpose !
But still, I believe there are much simpler ways to achieve RPC from
the browser ('cause that's where it all boils down to eventually).
Ways that don't require a deep understanding of a crappy protocol
originally designed for serving static documents, and that some crazy
guys pathetically try to turn into an ORB...
I know, it's harshe. But to me, the REST mood really looks like a
bunch of people turning something simple and effective for some given
use cases (post a request, get JSON back. period.) into something
complex and verbose that doesn't have any added value over the
"simple" version... Really, feels like I've already seen that movie.
Several times.
I really think POST + request parameters + interoperable data
interchange format is enough for the web. I don't understand the added
value of REST, knowing that it's not as simple as sending a request to
an URL, passing parameters, and getting a result back. Typing system
apart, this is... a function call ! There has never been any headers
or verbs in procedural languages... so back to my original question :
what's the point ? What use case is better implemented using pure REST
than a more simple and pragmatic approach ? I can't think about a
single example...
Anyway, I probably missed something, all those folks can't be wrong...
(even if they have proven they could by the past)
So I guess REST folks have reasons to use this type of "middleware",
even if I can't understand those (erf, nobody actually ever gave me
one).
But I agree on a given point : Stripes is probably a perfect
foundation for building a REST fwk... As I use to say, Stripes is what
the servlet API should be, so any piece of software that responds to
an HTTP request is probably easier to buid on top of our favorite web
fwk ;-P
Cheers
Remi
On Wed, Jul 9, 2008 at 5:50 PM, Will Hartung <[EMAIL PROTECTED]> 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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
