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=4447&dsMessageId=2591291 > >> > > >> > >> ------------------------------------------------------ > >> > >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591738 > >> > > > > > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591936 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591952
