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]> 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]>
> 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
>
-------------------------------------------------------------------------
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
