begin quoting Bob La Quey as of Wed, Oct 01, 2008 at 11:49:35PM -0700: > On Wed, Oct 1, 2008 at 10:29 PM, Darren New <[EMAIL PROTECTED]> wrote: > > Bob La Quey wrote: > >> > >> You seem to be confusing REST with caching among other things. Caching > >> != REST though REST often enhances caching. > > > > Oh, and describe for me the URI that represents "Decrement Fred's account by > > $100, and give $50 to Sally and $50 to whoever Sally names in her > > configuration record, all in one transaction." > > Well if you really want to know in Django I would use something like > > http://accounting.com/Decrement/Fred/Sally/Assigns/$100/$50/$50/ or some such.
This works fine except that you run afoul of idempotency and recurring activities (e.g., Fred gives Sally $100 every week). > Then the underlying frame work would parse all that (using regex for > the variables) and map it to a function. The function might look > something like transact(from, to, assigns=defaults) or some such. > Here the arguments come from the regex and the defaults came from > Sally's configuration file when to=Sally. The function, transact() > would be written to manipulate Python objects. I think a POST or PUT to create a new transaction resource would be what you'd want to do, and then you'd need another POST or PUT to put the transaction being described into effect. But this is building up state on the server side, albeit not hidden state. At a first stab (probably not uber-RESTful), I'd say you might start with: http://accounting.com/accounts/{user}/transactions a GET returns a list of transactions, and a form. a POST (of the form) would create a new transaction a PUTs and DELETEs would be ignored. http://accounting.com/accounts/{user}/transactions/{transactionid} a GET would return the source and destination accounts, and the appropriate amounts. a PUT would update the record. a POST would check that the data submitted matches the current transaction (if not, failure), and on a match, lock the resource (all further PUTs and POSTS fail) and effects the change to the underlying accounts. a DELETE would roll back an uncommitted transaction, and error if the transaction had already been committed. There's state, but it's explicit in the resources. Actions are idempotent -- GETs do not change things, multiple PUTs do not have side-effects, multiple POSTs don't cause repeated changes to the underlying accounts, and multiple DELETEs would not be a problem. Is that RESTful enough? Yes? No? Kinda-sorta? Miss the boat entirely? > In Django, and some other web frameworks, no thought or knowledge of > SQL on the part of the application programmer is needed. There is an > ORM (Object Relation Manager) that automates the mapping via SQL to > the database. The function transact() would automagically invoke the > ORM and through the ORM SQL and the database. > > You do not have to like it. You do not have to use it. But it works > (mostly, usual caveats and disclaimers). It is easy to understand at > the level of application programming. IMHO it certainly beats the hell > out of writing code to grind down to the SQL for a specific database. I thought the purpose of SQL was to (mostly) avoid having to worry about a specific database. > If you really do have to do that then Django specifically (and most > other frameworks as well) allows you to drop down to that level. So > far I have not had that need (Thank God.) Just wait until someone on your team locks you into Oracle with extensive non-portable stored procedures. > I have written more very low level code in my lifetime than I care to > think about. I started this game punching seven bit codes one bit at a > time into paper tape. I do not mind at all having automatons punch > bits and more for me. As I always say*: "If it's tedious or boring, let the computer do it." > > Or the URI that represents "Lock my mailbox against writing until I'm done > > reading my mail and I have decided what to delete and what to keep." Don't > > forget to unlock it if, for some reason, I finish without unlocking it. How can one tell if you've finished, or if you're merely very slow? > Sort of the same as above. I will leave it for others to develop the details. What is the purpose of locking? To have the list of email in a mailbox not change when new mail arrives, or when concurrent machines are modifying the same user's mailbox? What's the actual underlying task? [snip] > > Or the URI that represents my ssh session to the server over there. > > Hey that is a good one. It is late. I will tackle that one day after > tomorrow, cause tomorrow I go to San Diego and my day is shot. I do > think I can do that :) We shall see. http://tracking.host.tld/users/{user}/ssh/{sessionid}/ > > No, really, not everything is REST, and not everything can be > > represented as one independent round trip to a server and back. > > There really is state in the world. :-) > > Oh, I do agree there is state. I just think there is not nearly as > much of it as you seem to think. Also I am getting a lot of mileage > out of thinking of some state, for instance session, as simply > constucting an instance of a server, then for the duration of the > instance that server is stateless. Call it a bastardized view of REST > if you will but then I have never claimed to be a fundamentalist in > any church. Make state into a resource. Now you can handle it explicitly. > Father forgive me for I know I have sinned. > > Good clean fun, * Much to the continued dismay of my coworkers. -- Authentication and Authorization are some of the fun problems. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
