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
