Zbigniew Lukasiak wrote:
On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <[EMAIL PROTECTED]> 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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
