SJS wrote:
a POST (of the form) would create a new transaction
Great. Then your program crashes.
Again, you're building up state on the server that has to be tracked
between transactions, which is against the primary REST principle.
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.
You have conflated transaction processing with the semantics inside the
transaction. Why would I want a transaction to only work with accounts?
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.
That's basically how CouchDB works, except you don't actually need
transactions there because you only change one record at a time.
Ready for the next one? Two-phase commit.
Is that RESTful enough? Yes? No? Kinda-sorta? Miss the boat entirely?
It should be. I'm not sure what you mean by
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.
You've basically stopped modeling a database and instead turned your
URIs into stored procedures or something.
Part of the problem with transactions (and what I was trying to get at
with the "sally's choice" bit) was that sometimes you need to read the
DB, write the DB, read some other part of the DB, and then write some
more DB, then interact with some third system, then write the DB some
more, then roll back the transaction. I'm not sure quite how you do that
without having the possibility of something left locked.
I mean, sure, you can map "BEGIN TRANSACTION" to
http://sql/statement/begin%20transaction
You could use optimistic locking, where you pass back to the server each
value you think you've already read and let it see whether it's still
valid. But what benefit does that get you, other than massive overhead
on the server? It's not like you can switch DB servers in the middle of
the transaction and expect things to work. It's not like I can put
something in my shopping cart at this server, then look at that server
and reliably see what's in my cart.
I thought the purpose of SQL was to (mostly) avoid having to worry about
a specific database.
Distinguish "a specific database" from "a specific brand of database
server."
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?
That's precisely my point. You can't, if you use REST.
How do you know how long I looked at your web page? You wouldn't believe
the number of times the boss asked me to collect that statistic back in
the mid-90's.
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?
Concurrent processes. UNIX file systems suck, so the only way to remove
something from the middle of a file is to rewrite the whole file. Hence,
if new mail arrives while you're rewriting the file, you're screwed.
Sure, you can encapsulate it as a REST operation, but all you've done is
pushed it back and hidden it behind an interface. You can say "create a
URI that represents 'delete messages from the mailbox that are marked
to-be-deleted in an atomic manner'", but that doesn't answer how you
implement that when all you have is REST. You've just put the REST bit
in a hidden "stored procedure".
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}/
Sure. Now, what do I post to that URI, and where does the state for the
session ID get stored? Hint: if you're storing it at the server, then
it isn't REST.
Also, I'm pretty sure I don't want a post and return for every character
I write. X is already slow enough it works poorly over a mere T1, let
alone if every keystroke involved a full HTTP round trip.
Make state into a resource. Now you can handle it explicitly.
Sure. That's what REST means. It doesn't always work glibly. Imagine the
overhead of transferring your entire bittorrent state for every block
you transfer.
--
Darren New / San Diego, CA, USA (PST)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
