cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] RESTful web applications
Date Wed, 05 Dec 2007 22:16:36 GMT

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


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


Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message