RE: Re: What to do about sessions?
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 by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291
RE: Re: What to do about sessions?
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 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 by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738
Re: Re: What to do about sessions?
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 representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: 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 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 by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591774
Re: Re: What to do about sessions?
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 requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: 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 representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: 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 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 by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936
Re: Re: What to do about sessions?
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; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: 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 requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: 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 representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: 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 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 by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952
RE: Re: What to do about sessions?
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 by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591
