On Nov 7, 2008, at 3:04 PM, Robertson, Jeff wrote:
> Paul and Craig, you guys seem to be headed down the path of
> RESTifying not just web services, but web *applications*.
From the perspective of the REST style there is no difference between
a RESTful Web service and a RESTful Web application, the same
principles apply :-)
I hope i don't come across as too preachy :-) I hope that by
discussing this developers can make better pragmatic engineering
decisions and under stand the tradeoffs they are making for their
particular 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.
>
I believe there are a quite a few frameworks exploring this area e.g.
Rails, Grails, Django, Apache Sling etc.
Note that Jersey includes a @PerSession life-cycle even though i do
not recommend using it, because sometimes you just gotta get something
working or you have to integrate with existing stuff.
> It's interesting and encouraging to see Craig's involvement here.
Indeed!
Paul.
> 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.
>
> -----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
>