Cart
[Home] [By Thread] [By Date] [Recent Entries]
"Bullard, Claude L (Len)" <clbullar@i...> writes: > I'm not sure what you are trying to achieve. User A GETs a resource and edits it. User B GETs a resource and edits it. User A PUTs the modified resource back. User B PUTs her version of the modified resource back, unaware of A's edits. A's edits are lost without anyone noticing. What I want to happen is B to get a 409 "Conflict" or some such. > REST isn't a good idea for isolating a transaction unless that > transaction is expressed as a document. A lockfile is a document. Just not one I would have thought should be exposed to the user :=) > 1. REST doesn't remove the requirement for replication, as in, > a server collapsing under the load of both transactional > updates and deletes while simultaneously attempting to process > requests for reports. Create a report server and replicate to it. > REST is likely good for that. There are no replication requirement in this project. > 2. REST thrives as the granularity of a document/dataset; that is, a > report. Yes, that's why I want to know more about it :=) Ari. -- Elections only count as free and trials as fair if you can lose money betting on the outcome.
|
