Robertson, Jeff wrote:
> Paul and Craig, you guys seem to be headed down the path of RESTifying not just web services, but web *applications*. This is a much bigger, VERY ambitious goal, as I'm sure you know. It means reversing the course of web development in the Java world since Servlets. Somebody's got to do it, I guess.
>
>
Many aspects of the RESTful architectural approach are basically a given
in the Ruby on Rails community (which is where you'll find more than a
few Java refugees -- including me for much of the last couple of years),
although the technology does support sessions as well. Some of us are
coming back with stories of greener grass ... that actually *is* greener
:-).
> It's interesting and encouraging to see Craig's involvement here. Struts and JSF were both very much used for stateful web applications. The frameworks don't technically FORCE statefulness on the developer, but they sure don't discourage it. If Craig is now preaching the REST gospel, that's a pretty sure sign of which way the winds are blowing.
>
>
I hope so :-).
Craig
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Friday, November 07, 2008 8:57 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Web applications using XMLHttpRequest and JAX-RS REST/JSON Web Services
>
>
> On Nov 7, 2008, at 2:50 PM, Julio Faerman wrote:
>
>
>> Other point to consider is culture. Most developers stuff the sessions
>> because they are used to, and have doing so since, say, ASP 2.0.
>>
>
> Right. This is one reason for why a think HTTP auth in browsers is so
> poorly implemented and managed from a URI perspective.
>
>
>
>> In AJAX apps, it gets a little harder to get rid of the session, as
>> you need to fire smaller requests and do not want to keep track of
>> session information across pages, with is not nice in javascript.
>> Perhaps a new sample app with auth and stateless server, but with
>> contextual data. I think i can contribute this. Would it be relevant?
>>
>
> Very!
>
>
>
>> Any considrations or features that would be intersting to demonstrate?
>>
>>
>
> I cannot think of any thing specific. I would pick a common use-case
> and present an implementation that does not use sessions. The example
> might even throw up a few areas we could improve on in terms of the API.
>
> Paul.
>
>
>
>> On Fri, Nov 7, 2008 at 11:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
>> wrote:
>>
>>> On Nov 7, 2008, at 1:58 PM, Julio Faerman wrote:
>>>
>>>
>>>> I would like to discuss this further, i think it is a very common
>>>> question. Let me try do defend some "statefulness".
>>>>
>>>> 1- The overhead of session management is questionable, as there are
>>>> efficient persistence and replication mechanisms available in modern
>>>> app servers. If we are talking about a sufficiently large number of
>>>> server, the overhead is tolerable.
>>>>
>>>>
>>> It is yet another thing to manage and consider, especially when the
>>> deployment system changes. It makes it harder to route requests to
>>> the right
>>> set of machines each time. The implications of such session state
>>> can cross
>>> many boundaries in the layered and networked system, including
>>> clients, for
>>> example i cannot switch from buying an airline ticket on my laptop,
>>> bookmarking the URL, and switching to continue the process on my
>>> phone,
>>> perhaps in another country deferring to a bunch of servers close to
>>> my
>>> location for better performance.
>>>
>>>
>>>
>>>> 2- The use of HTTP-Basic auth is less secure, specially if not
>>>> using SSL.
>>>>
>>>>
>>> As the name suggests it is basic :-) but i would argue no less
>>> basic than
>>> many Web apps that send the password typed into the HTML form as
>>> part of the
>>> POST login message. Both have to be used with SSL.
>>>
>>>
>>>
>>>> 3- The session helps a lot when the information the system should
>>>> provide is contextualized to the authenticated user. For example,
>>>> showing the accounts of the salesperson using the system. A
>>>> stateless
>>>> app would require additional authorization checks to perform the
>>>> same
>>>> operation.
>>>>
>>> When you log in you have to authenticate and that authentication
>>> grants
>>> roles. Is that not independent of the authentication mechanism? The
>>> key i
>>> think is to ensure that the contextualized information is resource
>>> state
>>> identified by a URI associated with the user, or application state
>>> that is
>>> sent by the client to the server.
>>>
>>>
>>>
>>>> I tried hard to keep my current project completly "stateless", and i
>>>> agree on storing the minimum possible state in the session, but the
>>>> benefits of a small session outweights the cost in most
>>>> applications,
>>>> IMHO.
>>>>
>>>>
>>> I understand, pragmatically i can see why this is so. As i said i
>>> think the
>>> tools/frameworks have made it easy to leverage sessions rather than
>>> other
>>> mechanisms that do not leverage sessions that make better use of
>>> URIs.
>>>
>>> Paul.
>>>
>>>
>>>> On Fri, Nov 7, 2008 at 6:25 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
>>>> wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>> Well said! Further more you often find that some web sites will
>>>>> be hidden
>>>>> behind one URL. It is not book markable.
>>>>>
>>>>> The current state of affairs is this: at any one point in time
>>>>> how to do
>>>>> you
>>>>> know web sites you are logged into? how do you log out? the
>>>>> browser does
>>>>> not
>>>>> know really anything, because it is all opaque through server-given
>>>>> opaque
>>>>> identifiers, usually cookies.
>>>>>
>>>>> Would it not be nice for the browser, and therefore the user, to
>>>>> have
>>>>> more
>>>>> control over this? Utilizing HTTP authentication can enable this
>>>>> because
>>>>> the
>>>>> browser is aware of the authentication process. Unfortunately
>>>>> browsers
>>>>> today
>>>>> do a dreadful job popping up an ugly dialog box to login. I am
>>>>> sure there
>>>>> are ways to get nice login pages working with this type of
>>>>> mechanism but
>>>>> the
>>>>> frameworks and tools do not encourage this type of approach, thus
>>>>> the
>>>>> least
>>>>> path of resistance is to use a session, which can easily come to
>>>>> be a
>>>>> decision one might regret later on.
>>>>>
>>>>> Paul.
>>>>>
>>>>> On Nov 7, 2008, at 9:11 AM, Craig McClanahan wrote:
>>>>>
>>>>>
>>>>>> Craig McClanahan wrote:
>>>>>>
>>>>>>> Eduardo Pérez Ureta wrote:
>>>>>>>
>>>>>>>> Ideally I would like to use the servlet session.
>>>>>>>>
>>>>>> I should have responded to this particular statement in my
>>>>>> previous
>>>>>> response (sorry for the omission). And it relates to some
>>>>>> comments I
>>>>>> *did*
>>>>>> make that might not make a lot of sense without a little bit of
>>>>>> context.
>>>>>>
>>>>>> One of the key principles behind RESTful APIs is that they
>>>>>> should be
>>>>>> *stateless*. In other words, if the server is implemented as
>>>>>> multiple
>>>>>> instances of your application behind a load balancer, it should
>>>>>> not
>>>>>> matter
>>>>>> if the (n)th request and the (n+1)th request are served by
>>>>>> different
>>>>>> instances. This is a key attribute in designing an application
>>>>>> that can
>>>>>> scale beyond a single server instance.
>>>>>>
>>>>>> When you use servlet sessions, you are risking a violation of
>>>>>> this basic
>>>>>> principle. Let's assume that you are taking the typical
>>>>>> approach where
>>>>>> a
>>>>>> cookie is used to tell the client what session identifier to
>>>>>> submit on
>>>>>> subsequent requests. The usual server side implementation of a
>>>>>> "session" is
>>>>>> essentially a HashMap of session attributes, keyed by the
>>>>>> session id.
>>>>>> But
>>>>>> the *crucial* point is that this information normally lives only
>>>>>> within
>>>>>> the
>>>>>> context of a single JVM (i.e. a single instance of your server).
>>>>>> Supporting
>>>>>> an application that scales horizontally (that is, across
>>>>>> multiple server
>>>>>> instances) would require that either:
>>>>>>
>>>>>> * the load balancer recognize that a subsequent request belongs
>>>>>> to an
>>>>>> existing session on a *single* instance of your application,
>>>>>> which means
>>>>>> you are likely to experience service overloads if this single
>>>>>> instance
>>>>>> has
>>>>>> too many active sessions. (You will often see this referred to as
>>>>>> "sticky
>>>>>> sessions").
>>>>>>
>>>>>> * the server environment recognizes that there is an existing
>>>>>> session,
>>>>>> but
>>>>>> the data for it lives on some other server instance so it needs
>>>>>> to be
>>>>>> copied
>>>>>> to this instance before the request can be processed. As you can
>>>>>> imagine,
>>>>>> there can be significant overhead in doing this sort of thing.
>>>>>>
>>>>>> With respect to authentication (which was the particular context
>>>>>> of
>>>>>> Eduardo's questions), the standard HTTP approach is to include
>>>>>> an HTTP
>>>>>> header named "Authorization" with each request -- most typically
>>>>>> using
>>>>>> the
>>>>>> HTTP Basic authentication scheme (http://www.ietf.org/rfc/rfc2617.txt
>>>>>> ).
>>>>>> This means that the authentication operation must occur on *every*
>>>>>> request,
>>>>>> but it also means that you can indeed scale your application
>>>>>> across
>>>>>> multiple
>>>>>> server instances, because any one of them is capable of
>>>>>> performing the
>>>>>> authentication transaction. You would be wise, if you are
>>>>>> planning on
>>>>>> an
>>>>>> application that does, or even *might*, require deployment of
>>>>>> more than
>>>>>> one
>>>>>> instance, to keep this consideration in mind.
>>>>>>
>>>>>> For a Java developer who doesn't want to care about all the
>>>>>> nuances and
>>>>>> complexities of the HTTP protocol, my recommendation is pretty
>>>>>> simple --
>>>>>> figure out how to design your application without using
>>>>>> sessions. For
>>>>>> authentication, that's pretty simple ... just include the
>>>>>> authorization
>>>>>> header on each request (for human-interaction web applications,
>>>>>> browsers
>>>>>> even do this for you if your server is designed for HTTP Basic
>>>>>> authentication). For application state, everything that the
>>>>>> server
>>>>>> needs to
>>>>>> know about the current state should be included with each
>>>>>> request. (The
>>>>>> details of this topic is the source of many thesis-length
>>>>>> dissertations,
>>>>>> but
>>>>>> the fundamental principle is pretty easy to grok.)
>>>>>>
>>>>>> Or, of course, if you *know* your application will never need
>>>>>> more than
>>>>>> one instance (even to ensure availability in the case of an
>>>>>> instance
>>>>>> failure), you can safely ignore this advice. But can you really
>>>>>> be
>>>>>> sure?
>>>>>> (For a 10-user departmental app behind your company firewall,
>>>>>> sure you
>>>>>> can.
>>>>>> For an Internet facing app, no way IMHO. All it takes is a single
>>>>>> "Slashdot Effect" surge of interest in your app, which overloads
>>>>>> your
>>>>>> single
>>>>>> server instance, to demonstrate to you (and to the world,
>>>>>> unfortunately)
>>>>>> that you weren't ready for Internet scale user traffic).
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>