Ralph,
First I want to say, that I'm very much appreciating having this discussion with
you. Find my comments inline.
Ralph Goers wrote:
Reinhard Poetz said:
I agree with you but let me give you some reasoning that has lead to this
misture:
The problem is that developing really RESTful applications isn't entirely
possible with current web browsers, e.g. you can't use other methods than
POST
and GET in your forms. Additionally, you will have a hard life if you want
to
compete with full-blown web app frameworks like JSF, Wicket, Tapestry or
our own
cForms because all of them introduce some kind of abstraction layer (=
server-side forms) on top.
On the one side this is handy, on the other side you fight against the
nature of
the web (HTTP) to some extend. The better a framework, the less problems
you
will face as web application developer.
Isn't this pretty much what I said in an earlier post?
yep
One could argue now that if you use a framework that hides all those
alleged
limitations of HTTP fits your needs it doesn't matter whether you follow
RESTful
principles or not. However, IMO you lose a lot because if your web
applications
are implemented in a RESTful way, they are not only available for human
users
but also become useable by machines.
I don't buy this. A machine wants a service, a human wants an interface it
can interact with. The UI for the human may use that service, but in an
MVC sense the service is providing access to the model, not the view.
What makes you think that the view is providing access to the model?
machine -> RESTful service -> model
human -> GUI -> RESTful service -> model
My second argument was that most of today's web applications are developed
across two layers: One (bigger) part at the server's web-tier and one
(smaller)
part at the browser in the form of Javascript.
Gee, that is a bit user-centric. Classic design also calls for a business
tier and a data tier.
I didn't say anything that those layers are gone in a RESTful architecture. The
difference to 'classic' architectures is that your services expose resources
instead of offering remote procedure calls.
If you decide to go the RESTful way and want to develop web applications
that
can compete with those developed based on one of those full-blown web
frameworks, you will also need Javascript (event-handling, editing of
several
resources on one page, etc.). Probably, in comparison that's a bit more,
but
still manageable. In addition I expect that RESTful applications will be
less
complex.
Why? Because all the complication is in the Javascript library? I still
want to know how you are going to handle data that cannot or should not be
stored in the user's browser?
Can you be more specific here by giving an example?
<snip/>
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
