/
http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com
De : Matt Kennedy [mailto:stinkym...@gmail.com]
Envoyé : mardi 20 avril 2010 18:24
À : discuss@restlet.tigris.org
Objet : Re: What to do about sessions?
Dj,
I'm glad you asked this. I've
avril 2010 21:27
À : discuss@restlet.tigris.org
Objet : Re: What to do about sessions?
Well, I wrote my own NIO application server, so yes on both accounts!
Polling is not an option, I need to support thousands of concurrent
clients per hardware.
http://rupy.googlecode.com
/m
On Thu, 22 Apr 2010
It's hard for me to see Comet as RESTful. I would consider it a new
use of HTTP that demands a new way of thinking. You'd probably want to
use a lower level API than Restlet, so you can fully leverage
asynchronicity.
Have you considered repeat rapid polling instead of using Comet?
On
Well, I wrote my own NIO application server, so yes on both accounts!
Polling is not an option, I need to support thousands of concurrent
clients per hardware.
http://rupy.googlecode.com
/m
On Thu, 22 Apr 2010, Tal Liron wrote:
It's hard for me to see Comet as RESTful. I would consider it a
Hi Matt,
from what I see, the authenticator just have to check the presence of the user
principals (set by GAE) in the authenticate(Request, Response):
!request.getClientInfo().getPrincipals().get(0).
You can provide a verifier in order to check that the application knows the
user identified
I'm just chiming in to this, so this means with REST you have to send the
whole state back and fourth between client and server on every
request/response. So what does REST say about bandwidth, it's not a
problem?
Cheers,
/marc
On Wed, 21 Apr 2010, Thierry Boileau wrote:
Hi Matt,
from
REST services are definitely chatty, especially when compared to SOAP
webservices that might perform N operations in one shot.
To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a
client picks its way through multiple server resources via links that are
present in the
Hi Marc,
So what does REST say about bandwidth, it's not a problem?
If you use proxies to cache data, than you not waste, but save bandwith.
That's a (or the?) reason that sessions are not allowed. If you have
state on the server, than the cache / proxy can't know whats the server
state is
REST services are only as chatty as however you define your resources.
I've seen many REST architectures suffering from a failure of imagination:
the architects assume that resource has to have a one-to-one mapping with
database row or other concrete entity, when in fact there is not such
Ok, I realize you are all talking mostly from a B2B perspective. I'm
developing a realtime comet system for multiplayer games (Ajax, JSON,
Rupy); so my perspective is a little different.
Right now I'm trying to figure out how to make my XSS messaging system as
cheaply scalable as possible;
Hi dj,
session are strictly forbidden in REST, because the scalability advantage of
restful applications will get lost, because caches wont work. For details see
the dissertation of Roy Fielding, the founder of the REST architecture style,
espacially chapter 5
Hello,
as said Stephan, servlets sessions are not supported.
If a user logs in, I want to remember that they're
still logged in when they switch between pages, so they
don't have to keep re-authenticating.
There is no magic. If you have a look at each request issued from the browser,
you will
Hey Stephen,
Ok so I get that sessions shouldn't be supported by rest, totally fine with
that. I'm confused about how to use basic auth then instead, if that's the
preferred method.
If we use basic auth, then we need to send the username and password as plain
text, right? This could be fixed
Dj,
I'm glad you asked this. I've really lucked out so far and have always worked
in an environment that uses client certificates for authentication. The
identity of the user is established on every single connection, and I never
have to worry about it. But in the near future, I'm going to
14 matches
Mail list logo
