[
Lists Home |
Date Index |
Thread Index
]
Please pardon me for entering this thread a few weeks later, but
stepping out side of REST, this reminds me of some of the emerging Web
Services specs. More comments at end.
"K. Ari Krupnikov" wrote:
>
> David Megginson <dmeggin@attglobal.net> writes:
>
> > K. Ari Krupnikov wrote:
> >
> > > Suppose I want to build a RESTful interface to an ACID system. I want
> > > to allow the user to incrementally change the state of the system, but
> > > only "commit" the changes when he is satisfied with their sum. I
> > > imagine a user GETting a resource, POSTing some changes to it which
> > > may have side effects on other resources, GETting other resources to
> > > observe the side effects, and eventually committing to the changes or
> > > rejecting them.
> >
> > If the scope of the potential side effects is small and well-defined,
> > you might be able to reduce everything to a single exchange: get all
> > of the potentially-affected state to the client in a single XML
> > document (or collection of XML documents), allow the client to make
> > changes locally until satisfied, then post the modified state back to
> > the server. Since modifications live on the client side until
> > committed, there is no need to come up with any separate URL scheme.
>
> You are talking about a very thick client here. It's not how much
> state there is this application (not much), it's how much logic there
> is (a lot). The server already knows how to do this logic. I don't
> want to duplicate the logic on the client. I want to use a browser,
> and I don't want a ton of JavaScript to handle the state
> client-side. A full-blown Java client is a future possibility, but
> again, I'd like to keep the business logic in it to a minimum. I
> definitively don't want three separate codebases for business logic,
> one on the server one in JavaScript (possibly in multiple versions for
> different browsers) and one in a Java client.
>
> Client does presentation, server does business logic. Is that not in
> line with REST?
>
> > This approach would work for, say, a movie database, where the user
> > might check out a full movie description to change the director's
> > name, then check the entire description in again. It might not work
> > so well for, say, a geographical database, where a modification to a
> > shoreline may also require corrections to landuse data, roads and
> > railroads, and so on, in no easily-predictable way.
> >
> > It is entirely possibly that your project is one in the second
> > category, but I wouldn't give up on the simpler approach until it were
> > proven inadequate. Stupid-and-easy usually wins: moving 50K of XML
> > each way once can be much more efficient than many 100 byte
> > transactions.
>
> 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.
>
> Ari.
Stepping away from REST for a second (but acknowledging that REST was
your main intent), this is the essence of service-oriented architectures
(SOAs) - shared (non-redundant) business logic encapsulated as shared
services that can be published, discovered, and bound/invoked (at design
time and/or run time). The coordination aspects you discuss above are
covered by emerging specifications such as IBM/Microsoft/BEA's
WS-Coordination/WS-Transaction (WS-Transaction is now segmented into 2
specs, WS-AtomicTransaction and WS-BusinessActivity) [1][2], WS-Resource
Framework (WSRF) [3] from the Globus Alliance/IBM/HP, and OASIS
Composite Application Framework [4]. References [1][2][4] involve the
specification of a "coordinator" that coordinates the actions of
multiple Web services for requirements such as 2-phase commits, error
notification, etc. Reference [3] addresses interations of Web services
with stateful resources.
It is important to note that none of these specifications are "open
standards" (in OASIS and W3C-"like" terms) - the one closest to becoming
an open standards at this point is WS-CAF.
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wscoor.asp
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsacoord.asp
[3] http://www-fp.globus.org/wsrf/ModelingState.pdf
[4] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf
> --
> Elections only count as free and trials as fair if you can lose money
> betting on the outcome.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
