[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" <clbullar@ingr.com> 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.
|
