[Catalyst] Dispatching with Chained vs HTTP method

[Garrett Goebel]

Zbigniew Lukasiak wrote:
> On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <tjc at wintrmute.net> wrote:
>>  $id = POST transaction
>>  $amount = GET /user/1/account_balance
>>  $amount2 = GET /user/2/account_balance
>>  PUT /user/1/account_balance/$amount-1
>>  PUT /user/2/account_balance/$amount+1
>>  PUT transaction/$id?completed
>>     
>
> How about:
>
> $id = POST transaction
> PUT /transaction/$id/payer/1
> PUT /transaction/$id/receiver/2
> PUT /transaction/$id/amount/1
> PUT /transaction/$id?completed
>
> or even
>
> $id = POST transaction
> PUT /transaction/$id?payer=1;receiver=2;amount=1
> PUT /transaction/$id?completed
>   
A couple years back when I hacked together REST(like) CRUD with 
Catalyst... I opted for the latter. As it seemed at the time to be a 
better way to represent the possible keys to tuples.

I haven't been able to pay much attention to this thread. Not enough 
tuits. Sorry if I'm going over ground which has already been covered...

But I hope the people who are implementing it spend some time thinking 
about making the interface introspective.

Also important is how to allow people to limit which sets of tuples and 
relationships are publically accessible. For production work the default 
should probably require the REST interfaces to be explicitly published. 
Otherwise, with any set of tables with more than a handful of records, 
it will be fairly simple to bring the database to its knees with a URL 
that performs multiple joins on a large set of records. As a compromise, 
you might allow primary key candidates (keys which match exactly one 
record) and "have one" relationships to be public by default, but not 
"have many" or "many to many" relationships.

I think thinking in terms of using the underlying databases' 
transactions across multiple GET | PUT | POST | DELETE's is a mistake. 
For the reasons others have already pointed out. Except where you 
collect the data for your complex set of interrelated tuples and commit 
it in one go. Which of course means you need to be able to catch and 
handle the conflicts which can occur between starting to create your set 
of tuples and finally committing it.

cheers and good luck...

Garrett