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
