On Jul 9, 2008, at 9:43 AM, VANKEISBELCK Remi wrote: > On Wed, Jul 9, 2008 at 4:06 PM, Nick Stuart > <[EMAIL PROTECTED]> wrote: >> Ok Remi, we get it, you don't like REST wont use REST and think it >> sucks, >> but unless you have some constructive feedback here you are not >> contributing >> to the cause. > [...] > > 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 ? > > I'm trying to avoid people jumping into the REST trap too fast, as > there are precisely simpler ways to achieve the same goal, which is : > >> For REST/Stripes integration I definitely see it as more as way to >> allow >> Stripes apps to talk with other apps/services in a standard way. > > You can have your Stripes app *fully* invokable from any standard HTTP > client that understands JSON or XML, without *any* modification of > your existing logic. We already have such thing working since a while > now. Even better, for those who know a bit about middleware, the > approach allows to dynamically generate documentation and interface > descriptions, thus making Dynamic Invocation possible (which I believe > would work as well with Will's approach, as it uses reflect to > introspect the bean's events etc.). > > Really, no need for verbs or other bullshit, sorry. This is "fly > fucking" again :-P > > And again, don't be offended by my language, that's just how I am. > Think about the content, not the appearance : isn't proposing > alternatives "contributing to the cause" as well ?
I'm not all the way through the thread, which is a well timed thread. I'm looking for more powerful URL binding facilities in Stripes and wanted to ask about it. For me the power of the concept of REST is the Reprsentational State Transfer part of it. The ability to maintain the state of a page in meaningful URL. I despise other Java frameworks that treat the URL for my page as an implementation detail that needs to be abstracted away in a Java class that knows how to interpret a url full of MD5 hash looking strings. To my mind, the nice thing about REST is that you can created a bookmark, or copy and paste a link, and you'll go back to the same place, with the JavaScript controlled parts of the page in the same place. That you won't loose state to missing Cookies and forgotten form posts. But just like any simple idea, some people with nothing better to do went about formalizing it, which is always a painful process to watch. Resurrecting HTTP verbs? Are you kidding me? Why? What's wrong with the simplicity of GET for representational state transfer, POST for submitting content? You are write that this is absolute bullshit. Trying to force an atrophied part of the standard to life for the sake of some sort of completeness. Making it customizable, no less. It defeats entirely the core competency of REST in that it is *simple* and that you can invoke it using the most *basic* HTTP library. By resurrecting HTTP verbs you're now requiring a retro fitting of all the libraries, like Stripes that support the protocols that ordinary browsers use and the clients, which have no real capacity for anything but GET and POST (Oh, and the WebDAV which is, feh, not a filesystem, feh, not well supported, feh, don't use it.) REST is one of those things that was born of the best practices of the minimum common subset. If REST has become this monster that wants to turn HTTP into it's own SOAP, then I will make sure to find a new thing to call it. Something that talks about meaningful, type-able, boomark-able, URLs, redirect after post, GET for queries, POST for submissions only, cookies for user interfaces only. Why you can't simply use an action in the query string, lost on me. Remi is right. Just have an answer for serving up XML, JSON or plain text. Keep the latest Java world shinny-object fetish out of an elegant core framework. Programmers who lack the talent to create elegant programs instead devote their careers to developing complicated protocols. -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ ------------------------------------------------------------------------- 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
