I've often wished for a web framework in which there are no HTML(ish) view templates.. The view for each model class is determined by convention with help from annotations. Is anyone trying this?
--------------------------
Sent using BlackBerry
----- Original Message -----
From: Craig.McClanahan_at_Sun.COM <Craig.McClanahan_at_Sun.COM>
To: users_at_jersey.dev.java.net <users_at_jersey.dev.java.net>
Sent: Fri Nov 07 10:58:37 2008
Subject: Re: [Jersey] Web applications using XMLHttpRequest and JAX-RS REST/JSON Web Services
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.
Or servlet 2.0, which is now twelve years old.
Or JSP, which creates sessions by default unless you tell it not to. :-)
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?
Any considrations or features that would be intersting to demonstrate?
I think that would be awesome. Regarding structure, one thing I've seen in Ruby on Rails apps is the idea that your basic server side UI based webapp should follow exactly the same RESTful design principles, and then add a couple of methods to the controller to return the underlying data (for a particular page) in XML or JSON, instead of embedded in an HTML UI. Translated to Jersey terminology, that would mean using the same resource class for, say, a list of customers for the currently logged on sales person. If the client requests HTML they get the normal UI (which might have embedded javascript inside to perform Ajax calls later); if they ask for JSON or XML they just get the underlying data.
Craig
On Fri, Nov 7, 2008 at 11:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> <mailto: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> <mailto: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