Cart
[Home] [By Thread] [By Date] [Recent Entries]
I'm not sure what you are trying to achieve. REST isn't a good idea for isolating a transaction unless that transaction is expressed as a document. Except possibly for tracing and logging (keep the instance around which is what is done with SQL statements for so-called 'deep logging'), I'm not sure what you are trying to do with REST that can't be better done with standard SQL. 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. 2. REST thrives as the granularity of a document/dataset; that is, a report. Else one is defining a column/row as a resource. That won't work, or at least, the pain of it is unacceptable in a stateless system. Coarse granularity means exactly that: not for fine granular operations. len From: ari@c... [mailto:ari@c...] David Megginson <dmeggin@a...> writes: > K. Ari Krupnikov wrote: > > > Client does presentation, server does business logic. Is that not in > > line with REST? > > I'll leave it to the RESTafarians to answer that question, but sending > one big chunk of information is nicely in line with the XML ideal of > separating information from processing. It doesn't solve the lost update problem.
|
