There have been countless flamewars on this subject... we need another one here ;-) As you guess, I think 3) is the way to go (although it doesn't have to be limited to crud operations). I tend to trust Thomas Erl here (http://www.soaprinciples.com/service_statelessness.asp). Me and my team use json-rpc, which is pretty much the same as xmlrpc, and most methods require a token, used only for auth ("can this client use this method ?"), no state is kept on the server. We also consume SOAP services that are not designed following the stateless principle and it's a real pain in the... we even have to call methods in a particular order just because they're not autonomous :-/ Of course you may have different needs but since they don't seem to be covered by the xmlrpc protocol, you should probably address them in your application. It shouldn't be too difficult to pass the cookie value in the url, or as a parameter and then find the session data on web2py side. The problem is that there's no real standard for this, so any implementation in web2py will probably remain web2py-specific. It's probably ok, if it's not activated by default.
On 13 août, 09:34, rb <[email protected]> wrote: > > Furthermore, a "good" service should be designed to work > > with no state. State is the client's job, not the service, and this > > makes your service more scalable. > > An n-tier (web) app has at least a database facility, business logic > facility, and presentation. Your comment above implies that all > business logic should exist in the client - and not in the svr, > because only trivial business logic is stateless. I don't think this > is necessarily true. The choices really boil down to three: > > 1) put stateful business logic in the svr, keep it active, and pass a > session token between client and svr (ie keep the state active in the > svr); > > 2) serialize the business logic state to disk (or cache) and then > throw away the state, and reconstitute the state upon each following > client request in the session (keep the state in the server but > unserialize and serialize it with each client request); > > 3) keep the business logic and its state (active) in the client and > only send stateless CRUD back to the svr. > > I see advantages and problems with all three approaches. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
