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
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;
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
6 matches
Mail list logo
