[
Lists Home |
Date Index |
Thread Index
]
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@cogsci.ed.ac.uk [mailto:ari@cogsci.ed.ac.uk]
David Megginson <dmeggin@attglobal.net> 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.
|
