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.
2- The use of HTTP-Basic auth is less secure, specially if not using 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.
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.
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
>
>