users@jersey.java.net

Re: [Jersey] Web applications using XMLHttpRequest and JAX-RS REST/JSON Web Services

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 07 Nov 2008 14:56:34 +0100

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
>