You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/12/05 14:00:27 UTC
[RT] RESTful web applications
Carsten Ziegeler wrote:
> I might be mistaken but I have the feeling that this discussion mixes
> things a little bit. Once thing is REST and another thing is javascript.
> I can use/follow one of them wihtout using/following the other.
>
> It might be true that using AJAX makes developing RESTful applications
> easier, but again I can do the one without the other.
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.
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.
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.
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.
For me those are the reasons why I said that I have changed the camp and think
that Stefano was right with his opinion that traditional web frameworks would
become obsolete. But, in contrast to him, I think that Cocoon, which in some
respect isn't 'traditional' at all, can become the ideal server-side counterpart
for such RESTful web applications.
--
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 reinhard@apache.org
_________________________________________________________________________
Re: [RT] RESTful web applications
Posted by Juanjo Vázquez <jv...@apache.org>.
Hi,
I think this is a really great idea. In the past months, I have been working
with AJAX-RESTful architectures. For instance, I have mixed Ext js [1] with
Cocoon 2.2 as XML provider and SOAP Web Services as services provider.
Although, I think Cocoon 2.2 is a too big stuff if only it´s dedicated to
produce XML. A "microCocoon" could be a goog idea.
BR,
Juanjo.
[1] http://extjs.com/
On Dec 5, 2007 3:16 PM, Reinhard Poetz <re...@apache.org> wrote:
> Sylvain Wallez wrote:
> > Reinhard Poetz wrote:
> >
> > <snip/>
> >
> >> For me those are the reasons why I said that I have changed the camp
> >> and think that Stefano was right with his opinion that traditional web
> >> frameworks would become obsolete. But, in contrast to him, I think
> >> that Cocoon, which in some respect isn't 'traditional' at all, can
> >> become the ideal server-side counterpart for such RESTful web
> >> applications.
> >
> > Interesting! Can you elaborate on why you think Cocoon is great for
> > RESTful applications? Is it because of its URL pattern matching
> features?
>
> That's one half of the story. The other one is XML pipelines and content
> aggregation on an XML level (XML plays in many RESTful architectures an
> important role, at least in ours) which make Cocoon still very appealing
> to me.
> Actually all three together are the virus that has infected me long time
> ago at
> the good old Cocoon 2.0alphaX days.
>
> - o -
>
> Recently I've been thinking more and more about some kind of
> "Micro-Cocoon"[*]
> that consists of
>
> o a slimmed-down sitemap language available in as an XML and as a Java
> dialect
> (no component declarations, no sub-sitemaps, no resources, merged
> match/select),
> o a controller implementation that is optimized for being used in RESTful
> scenarios (similar to Apples) and
> o a lean forms framework that borrows some ideas from Webforms 2.0 and
> follows the principles of REST. Daniel and I had some discussions about
> it in
> Rome and I've started with some experiments but don't have anything
> substantial so far.
>
> All the parts mentioned above should be useable in parallel with a
> traditional Cocoon 2.2 application. Thanks to the servlet-service
> framework this
> shouldn't be too hard to be achieved.
>
> If this sounds interesting to anybody, just let me know.
>
>
> [*] borrowing the term "micro" from Bertrand who used it for a slimmed
> down
> version of Sling which seems to be another (too) huge beast in the webapp
> framework arena.
>
> --
> 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 reinhard@apache.org
> _________________________________________________________________________
>
Re: [RT] RESTful web applications
Posted by Peter Hunsberger <pe...@gmail.com>.
On Dec 5, 2007 8:16 AM, Reinhard Poetz <re...@apache.org> wrote:
>
>
> Recently I've been thinking more and more about some kind of "Micro-Cocoon"[*]
> that consists of
>
> o a slimmed-down sitemap language available in as an XML and as a Java dialect
> (no component declarations, no sub-sitemaps, no resources, merged
> match/select),
> o a controller implementation that is optimized for being used in RESTful
> scenarios (similar to Apples) and
> o a lean forms framework that borrows some ideas from Webforms 2.0 and
> follows the principles of REST. Daniel and I had some discussions about it in
> Rome and I've started with some experiments but don't have anything
> substantial so far.
>
> All the parts mentioned above should be useable in parallel with a
> traditional Cocoon 2.2 application. Thanks to the servlet-service framework this
> shouldn't be too hard to be achieved.
>
> If this sounds interesting to anybody, just let me know.
>
That's been on my wish list for about three years now. Either Cocoon
2.2 has to grow into a system that can be pared down into a sort of
micro sized core or we'll end up finding another solution. We just
don't need all the extra _stuff_ (<-- technical term)...
--
Peter Hunsberger
Re: [RT] RESTful web applications
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 5, 2007 3:16 PM, Reinhard Poetz <re...@apache.org> wrote:
> ...[*] borrowing the term "micro" from Bertrand who used it for a slimmed down
> version of Sling which seems to be another (too) huge beast in the webapp
> framework arena....
I would have been shy mentioning microsling here, so thanks ;-)
The goals of Sling and microsling [1] are somewhat similar to what you
mention, that is helping people think in REST terms and providing
powerful scriptable server-side components to build REST applications.
Being JCR backed, though, makes XML mostly unnecessary in microsling,
and that makes things much simpler when dealing with content, by
avoiding markup until the very end of the request processing.
microsling uses templates based on server-side javascript (Rhino of
course).
The need for XML might resurface in Sling to produce documents in
formats like PDF or SVG - and for that a micro-Cocoon (we'd just need
embeddable pipelines, basically) might make a lot of sense. The itch
hasn't been strong enough to require scratching yet, but that will
probably happen sooner or later.
-Bertrand
[1] http://svn.apache.org/repos/asf/incubator/sling/trunk/microsling/microsling-standalone/
Re: [RT] RESTful web applications
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>> Recently I've been thinking more and more about some kind of
>> "Micro-Cocoon"[*] that consists of
>>
>> o a slimmed-down sitemap language available in as an XML and as a
>> Java dialect
>> (no component declarations, no sub-sitemaps, no resources, merged
>> match/select),
>
> I wrote a simple Java library about 2 years ago (time flies!) that
> mimics the major features of the sitemap: pattern matching and variable
> substitution calling plain old servlets rather than pipelines. Not more
> than a dozen of classes :-)
Sounds interesting. We haven't decided it yet, if we really go the way of
working on a "Micro-Cocoon", but if we do so we will definitly share our
thoughts and findings with this list and I hope that you can share your
experiences with us then.
>> o a controller implementation that is optimized for being used in
>> RESTful
>> scenarios (similar to Apples) and
>> o a lean forms framework that borrows some ideas from Webforms 2.0 and
>> follows the principles of REST. Daniel and I had some discussions
>> about it in
>> Rome and I've started with some experiments but don't have anything
>> substantial so far.
>>
>> All the parts mentioned above should be useable in parallel with a
>> traditional Cocoon 2.2 application. Thanks to the servlet-service
>> framework this shouldn't be too hard to be achieved.
>>
>> If this sounds interesting to anybody, just let me know.
>
> It does sound interesting. Now I'm wondering if XML pipelines still fit
> in the web application landscape. They are perfect for publication
> purposes, but webapps nowadays have been completely infected by Ajax
> and/or components approaches.
>
> On one hand, component-oriented approaches like GWT or Wicket
> essentially hide the HTTP protocol in favor of application-level Java
> code, and on the other hand the use of pure Ajax libraries such as Dojo,
> YUI, Ext and the like leads the browser to become a REST client using
> plain XML or JSON responses.
yes, agreed
>>>From a REST point of view, this dichotomy is interesting since
> component-oriented approaches ignore REST principle while Ajax libraries
> more or less require to design applications as a set of REST services,
> thus making them almost ready for machine clients.
>
> But in both cases, XML pipelines are not really needed anymore IMHO,
> except as you mention to aggregate remote sources. But it is then more a
> concern of the business-logic side of the application rather than that
> of the part handling client requests.
In our case we have to provide several (similar) representation formats
(different views and/or output formats) of one and the same resource. We could
either do it by writing additional templates or by using XML transformations.
Since we are fluent in XSLT, this is by far the most productive way _for us_ to
implement it.
> About the limitations of current browsers wrt to the full set of REST
> features (e.g. methods other than POST and GET), the book "Restful Web
> Services" [1] proposes a number of interesting workarounds such as using
> a request parameter (which can be a hidden form field) to override some
> headers or complement the request.
yes, RoR solves this problem this way, AFAIK.
> We could imagine a simple request
> filter that interprets these workarounds to present the servlets with
> the real "pure" REST requests.
good idea
--
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 reinhard@apache.org
_________________________________________________________________________
Re: [RT] RESTful web applications
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>> Reinhard Poetz wrote:
>>
>> <snip/>
>>
>>> For me those are the reasons why I said that I have changed the camp
>>> and think that Stefano was right with his opinion that traditional web
>>> frameworks would become obsolete. But, in contrast to him, I think
>>> that Cocoon, which in some respect isn't 'traditional' at all, can
>>> become the ideal server-side counterpart for such RESTful web
>>> applications.
>>
>> Interesting! Can you elaborate on why you think Cocoon is great for
>> RESTful applications? Is it because of its URL pattern matching
>> features?
>
> That's one half of the story. The other one is XML pipelines and
> content aggregation on an XML level (XML plays in many RESTful
> architectures an important role, at least in ours) which make Cocoon
> still very appealing to me. Actually all three together are the virus
> that has infected me long time ago at the good old Cocoon 2.0alphaX days.
>
> - o -
>
> Recently I've been thinking more and more about some kind of
> "Micro-Cocoon"[*] that consists of
>
> o a slimmed-down sitemap language available in as an XML and as a
> Java dialect
> (no component declarations, no sub-sitemaps, no resources, merged
> match/select),
I wrote a simple Java library about 2 years ago (time flies!) that
mimics the major features of the sitemap: pattern matching and variable
substitution calling plain old servlets rather than pipelines. Not more
than a dozen of classes :-)
> o a controller implementation that is optimized for being used in
> RESTful
> scenarios (similar to Apples) and
> o a lean forms framework that borrows some ideas from Webforms 2.0 and
> follows the principles of REST. Daniel and I had some discussions
> about it in
> Rome and I've started with some experiments but don't have anything
> substantial so far.
>
> All the parts mentioned above should be useable in parallel with a
> traditional Cocoon 2.2 application. Thanks to the servlet-service
> framework this shouldn't be too hard to be achieved.
>
> If this sounds interesting to anybody, just let me know.
It does sound interesting. Now I'm wondering if XML pipelines still fit
in the web application landscape. They are perfect for publication
purposes, but webapps nowadays have been completely infected by Ajax
and/or components approaches.
On one hand, component-oriented approaches like GWT or Wicket
essentially hide the HTTP protocol in favor of application-level Java
code, and on the other hand the use of pure Ajax libraries such as Dojo,
YUI, Ext and the like leads the browser to become a REST client using
plain XML or JSON responses.
>From a REST point of view, this dichotomy is interesting since
component-oriented approaches ignore REST principle while Ajax libraries
more or less require to design applications as a set of REST services,
thus making them almost ready for machine clients.
But in both cases, XML pipelines are not really needed anymore IMHO,
except as you mention to aggregate remote sources. But it is then more a
concern of the business-logic side of the application rather than that
of the part handling client requests.
WDYT?
About the limitations of current browsers wrt to the full set of REST
features (e.g. methods other than POST and GET), the book "Restful Web
Services" [1] proposes a number of interesting workarounds such as using
a request parameter (which can be a hidden form field) to override some
headers or complement the request. We could imagine a simple request
filter that interprets these workarounds to present the servlets with
the real "pure" REST requests.
Sylvain
[1] http://www.oreilly.com/catalog/9780596529260/
--
Sylvain Wallez - http://bluxte.net
Re: [RT] RESTful web applications
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
> <snip/>
>
>> For me those are the reasons why I said that I have changed the camp
>> and think that Stefano was right with his opinion that traditional web
>> frameworks would become obsolete. But, in contrast to him, I think
>> that Cocoon, which in some respect isn't 'traditional' at all, can
>> become the ideal server-side counterpart for such RESTful web
>> applications.
>
> Interesting! Can you elaborate on why you think Cocoon is great for
> RESTful applications? Is it because of its URL pattern matching features?
That's one half of the story. The other one is XML pipelines and content
aggregation on an XML level (XML plays in many RESTful architectures an
important role, at least in ours) which make Cocoon still very appealing to me.
Actually all three together are the virus that has infected me long time ago at
the good old Cocoon 2.0alphaX days.
- o -
Recently I've been thinking more and more about some kind of "Micro-Cocoon"[*]
that consists of
o a slimmed-down sitemap language available in as an XML and as a Java dialect
(no component declarations, no sub-sitemaps, no resources, merged
match/select),
o a controller implementation that is optimized for being used in RESTful
scenarios (similar to Apples) and
o a lean forms framework that borrows some ideas from Webforms 2.0 and
follows the principles of REST. Daniel and I had some discussions about it in
Rome and I've started with some experiments but don't have anything
substantial so far.
All the parts mentioned above should be useable in parallel with a
traditional Cocoon 2.2 application. Thanks to the servlet-service framework this
shouldn't be too hard to be achieved.
If this sounds interesting to anybody, just let me know.
[*] borrowing the term "micro" from Bertrand who used it for a slimmed down
version of Sling which seems to be another (too) huge beast in the webapp
framework arena.
--
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 reinhard@apache.org
_________________________________________________________________________
Re: [RT] RESTful web applications
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
<snip/>
> For me those are the reasons why I said that I have changed the camp
> and think that Stefano was right with his opinion that traditional web
> frameworks would become obsolete. But, in contrast to him, I think
> that Cocoon, which in some respect isn't 'traditional' at all, can
> become the ideal server-side counterpart for such RESTful web
> applications.
Interesting! Can you elaborate on why you think Cocoon is great for
RESTful applications? Is it because of its URL pattern matching features?
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] RESTful web applications
Posted by Reinhard Poetz <re...@apache.org>.
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 reinhard@apache.org
_________________________________________________________________________
Re: [RT] RESTful web applications
Posted by Ralph Goers <Ra...@dslextreme.com>.
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?
>
> 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.
>
> 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.
>
> 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? The argument that there isn't any (which you
haven't made) just isn't the case.
>
> For me those are the reasons why I said that I have changed the camp and
> think
> that Stefano was right with his opinion that traditional web frameworks
> would
> become obsolete. But, in contrast to him, I think that Cocoon, which in
> some
> respect isn't 'traditional' at all, can become the ideal server-side
> counterpart
> for such RESTful web applications.
No offense to Stefano, but I don't think he has ever worked at a bank.
But yes, Cocoon should easily be able to handle this.
Ralph