But doesn't that kind of defeat the argument that REST is just utilizing more of the HTTP spec if the spec is ambiguous in places? If the spec said POST IS CREATE, DELETE IS DELETE, then fine. But they can both mean DELETE according to what I've been reading. So I guess where does the spec end and REST take over completely? In each framework?
I'm really playing devil's advocate more than anything at this point. I'm not saying REST is bad or good. I'm really neither here nor there in either direction on it. What I am saying though is that if you argue specification/protocol... Gregg Nick Stuart wrote: > Yes RESTful URLs are a big part of the whole REST movement and a big > reason why a lot of people use it. And I think (for the most part), > that besides know the basics of how the verbs line up to what that > that's the minimum a developer would need to know to use rest (not > implement it obviously). > > And they verbs only overlap in our 'old school' way of thinking. (note > I'm not saying its all wrong, but still...) If we had those > definitions for REST then yes it would be confusing, but where I read > each verb as one action associated with it. If you don't do that, then > yes, everything would just be confusing and not really gain anything > over just using POST, as remi pointed out POST works for everything > right now anyways. > > I think its really just a matter of thinking in terms of REST when you > use it. If you try and mix and match then you will just confuse yourself. > > My ever decreasing in value $0.02 worth. > -Nick > > On Thu, Jul 10, 2008 at 9:15 AM, Gregg Bolinger > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > 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]> <mailto:[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]> > <mailto:[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> > > <mailto: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 > <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 > <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
