My confusion with REST (this really doesn't relate to whether or not a stripes extension should support it) is that from the reading I've been doing it is more about RESTful URLs than the protocol itself. I see more RESTful proponents that mention the HTTP protocol in passing rather than up front. Its all about:
http://..../user/1234 Where do the verbs come in to play here? / I think the VERBs most commonly used in REST (PUT, GET, DELETE, POST) are all pretty self explanitory, or at the very least, easy enough to describe./ But they overlap. POST - Create, Update, Delete GET - Read PUT - Create, Overwrite/Replace DELETE - Delete So its not at clear cut as the REST folks want you to think. Sure, your RESTful framework can put constraints on the protocol by say, requiring a DELETE to actually delete rather than a POST. But the protocol itself seems flawed to not inherently specify that. Just my 2 cents. Gregg Nick Stuart wrote: > > See Remi this is where I get confused. You say REST makes everything > more complicated and that POST is enough. The thing is though, that > besides the implementation by whatever framework for REST (which only > really needs to be understood/coded by a few folk) it's no more > complicated from the users of that particular framework perspective. I > think the VERBs most commonly used in REST (PUT, GET, DELETE, POST) > are all pretty self explanitory, or at the very least, easy enough to > describe. I just don't see where you get all these complications from. > As Will pointed out REST can be thought of as a 'lightweight' SOAP for > a lot of things. If you want to make it really dumbed down just think > as REST as kind of a automatic Action mapper for incoming requests. > > Also, I do want to say that I know REST doesn't fit everywhere and > wouldn't make sense to use everywhere. Heck, most of our app here > doesn't and wont use it, but there are some parts where it would fit > nicely. I am not saying REST is a magic bullet, and I do agree that > people that think that way are going a little to far, but I can a > place in the great expanse of intertubes for it. > > -Nick > > > On 7/10/08, *VANKEISBELCK Remi* <[EMAIL PROTECTED] <mailto:[EMAIL > PROTECTED]>> > wrote: > > 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] <mailto:[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 > <mailto:Stripes-users@lists.sourceforge.net> > 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 > Stripes-users@lists.sourceforge.net > 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 Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
