cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Servlet service request
Date Sun, 02 Dec 2007 15:05:43 GMT
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Grzegorz Kossakowski wrote:
>>  
>>> It may sound controversial but I think that things like information 
>>> about user locale or preferences
>>> should be kept in URL (preferably in path part or in request 
>>> parameters). If data set is too big,
>>> URL should contain an unique identifier of this data set. I mean, 
>>> instead of using following URL:
>>> /blog/posts/1
>>> and passing following information: Locale=pl-PL, 
>>> Username=gkossakowski, Skin=red
>>> it's better to have following URL:
>>> /blog/languages/pl-PL/skins/red/posts/1
>>>
>>> Or, if username is needed for other reasons (like we need to access 
>>> other preferences):
>>> /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1
>>>
>>>     
>> Yes, following the REST principle is a good way to build web
>> applications (and their URLs) - but that's not always possible/desired.
>> There is information you definitly don't want to put into the URL for
>> security reasons (Ralph outlined some of them) - and a URL has a maximum
>> length - and sooner or later you'll hit this limitation if you want to
>> put everything into the URL.
>>   
> I suppose REST is fine for some trivial applications on the web tier, 

I disagree with this statement. REST is an architectural style and I'm sure, 
following those principles will help you to build applications from trivial to 
very complex.

I also think that the mentioned "without sessions your apps don't scale" 
argument is bogus. If that was true, HTTP (which is the most prominent 
implementation of REST) wouldn't scale.

> but many modern web frameworks (i.e. JSF, Spring Webflow, Wicket) 
> require that state be maintained on the server simply because they have 
> a requirement that pages be accessed in specific orders. 

Using sessions for that purpose is just one way to implement it.

If you implement a RESTful web tier, your clients (e.g. web browsers) have to 
become more powerful. In times of mature Ajax frameworks, Flex etc. this isn't 
as much of a problem like a few years ago.

It took me a bit longer than Stefano, but in the meantime I also think that web 
framworks as we know today have already passed their zenith. Next generation web 
frameworks will make it simple to implement your webapps following REST and I 
think that Cocoon with its XML pipelines can shine again.

> I believe even 
> flowscript and Javaflow require this to preserve the continuations.  
> REST between the web tier and the business tier is a different matter. 
> The business tier should always be stateless and REST (as a concept) 
> works very, very well for that. However, when you start talking REST vs 
> SOA vs RPC the lines can get very blurry. I would contend that it is 
> possible to actually implement something in the business tier that is 
> actually all three.

yes, definitly possible but IMHO really not disired.

>> I think Ralph put it very nicely:
>>  
>>> I think the answer is simple. The session needs to be shared with all
>>> servlets in a webapp just as the servlet spec provides. Anything less
>>> is going to confuse the heck out of users, lead to nothing but trouble
>>> in the long run and give the impression that Cocoon just tries to make
>>> everything hard on purpose.

Although I wouldn't recommend the usage of sessions, I agree with Ralph and 
Carsten that we shouldn't forbid the usage of sessions. From our past 
experiences with our own contracts (e.g. the Cocoon environment abstraction, the 
FOM) we know that all those attempts haven't been very successfull over the time.


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

Mime
View raw message