On Thu, Oct 2, 2008 at 12:32 AM, SJS <[EMAIL PROTECTED]> wrote:
> 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.
An example from the Django book shows how this sort of thing works:
urlpatterns = patterns('',
(r'^articles/(?P<year>\d{4})/$', views.year_archive),
(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', views.month_archive),
)
The (?P<year>\d{4}) maps the results of the regex d{4} into the
variable year in the function views.month_archive etc.
> 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.
I would probably use a GET to create the new resource and a POST to
update it. But this is the sort of thing that REST aficionados haggle
over. Generally the haggling involves round tripping with RFC 2616
(HTTP 1.1) ... I do not have th etime this morning :)
> 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?
Good enough for me. One point though, all those GET, POST, etcs will
often get wrapped up in a single function called by the URI (or if you
prefer identified by the URI and called by the dispatcher.)
In Django you see this pattern often:
def contact(request):
if request.method == 'POST':
form = ContactForm(request.POST)
else:
form = ContactForm() # The initial GET grabs this one with
default data.
return render_to_response('contact.html', {'form': form})
So the request method is used to select the relevant code.
>> 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.
He,heh! What team? As one of my ex-wives said in a moment of extreme
clarity, "The only people you can work with are other people who
cannot work with anyone either."
[snip, gotta go now to SD today.]
BobLQ
--
KPLUG-LPSG@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
