Lists Home |
Date Index |
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. The server can send a big chunk of XML to the
client without having to know anything about how the client works; the
client can modify that information and send it back to the server without
having to know anything about how the server works. Of course, both sides
have a negative option: the client can refuse the XML sent by the server or
the server can refuse the modified XML returned by the client.
With an approach like this, the client can be anything from an autonomous
Perl script that fires up a text editor -- your server doesn't have to know
(and neither do you, when you're writing the server). Furthermore, the
client's logic is in no way constrained: it can work with the information
any way it wants, as long as the server is willing to accept what it sends
back. This is a very useful benefit, since few of us are smart enough to
anticipate all the different ways people might work with any kind of
I agree that this kind of approach cannot work for all applications.
Sometimes the user needs to edit information with strong dependencies on
other information that the server needs to keep hidden; other times, the
interdependencies are simply too complex to be covered by a single XML snapshot.
> It's not about reducing redundant traffic, it's about reducing
> redundant logic. One node should know how to do a process, be the
> final authority and bear the ultimate responsibility for that process.
Again, I agree that there are places that that approach makes sense, but one
of the biggest benefits of XML is the ability to allow a potentially
unlimited number of different processes to work with the same XML information.
All the best,