Ian Bicking: the old part of his blog

Re: RESTful transactions (a speculation)

Yikes. I propose two reasons you'd rather head down a different path.

  1. I expect that usually when you want to update several things at once, you're doing something singularly nameable; ie, there's a further abstraction to the group of work that is a resource. In OHM I see this issue, each attribute is individually accessible, but although we've grouped them into an object's attributes conceptually, there's no way to access or offer that conceptual grouping. OHM-level support for record and collection (tuple and relation :) abstractions should be implemented, even if it's just a set of conventions that we don't know yet. If we can name the set of data we're updating (at the simplest level, SO's o.set vs o._set_X), we can REST it in one request. The abstraction part comes from seeing your data as a relational database with idealized views.
  2. We still have to make use of mechanisms where it is each resource's responsibility to ensure its state transition is atomic when reacting to a side-effect verb, because any abstraction over URL-based referencing means process boundary is no different from server boundary or network boundary. How do you architect this differently when your mindset is thinking about having a change on this site need to set something else on another site? Same as within parts of your site that you may end up partitioning by machine or farm out to a third party. Rhetorically, does the reliability of that inner resource impact the assumptions of the original code when you could count on a local transaction? If updating your marriage status should be reflected in your holy rewards program availability, is two-phase commit with an optimization if we're lucky enough to be on the same process really the mechanism that comes to mind? Mines a little blurry.

Peace, Luke

Comment on RESTful transactions (a speculation)
by Luke Opperman

Comments:

Ok, found the article I'd printed out (!) on this subject, the original PDF seems to have disappeared but google cache is http://209.85.165.104/search?q=cache:44SdWHeWNXcJ:www-db.cs.wisc.edu/cidr/cidr2007/papers/P15.pdf&hl=en&ct=clnk&cd=1&gl=us

"Life beyond Distributed Transactions" by Pat Helland

# Luke Oppperman

I expect that usually when you want to update several things at once, you're doing something singularly nameable; ie, there's a further abstraction to the group of work that is a resource. In OHM I see this issue, each attribute is individually accessible, but although we've grouped them into an object's attributes conceptually, there's no way to access or offer that conceptual grouping.

If you do want to do this in OHM, you can create an attribute that is located at the root of the object (url_path=""). This can be a property that aggregates all the attributes of the object. If they are all JSON, you could do:

class MyObject(object):
    ... all the other attrs ...
    all_attrs = ['a', 'b', ...]
    def complete_state__get(self):
        return dict((attr, getattr(self, attr))
                    for attr in self.all_attrs)
    def complete_state__set(self, data):
        for name, value in data.items():
            assert name in self.all_attrs
            setattr(self, name, value)
    complete_state = property(complete_state__get, complete_state__set)

class MyObjectWrapper(ohm.server.ApplicationWrapper):
    complete_state = ohm.server.JSONSetter(uri_path='')

With XML you could do something similar, though actually creating the documents involves more documentation and details. But if you have heterogeneous types in your resources this doesn't work so well. For instance, I also attach a file server to the object that accepts PUT, MKCOL, and DELETE. Or some objects may be JSON, and others XML documents, and some operations might really be POST operations, and so forth. Mixing these into one document just doesn't work.

So what I describe here is really the same process, only it's amenable to any kind of document types. And I suppose eclectic HTTP methods.

We still have to make use of mechanisms where it is each resource's responsibility to ensure its state transition is atomic when reacting to a side-effect verb, because any abstraction over URL-based referencing means process boundary is no different from server boundary or network boundary. How do you architect this differently when your mindset is thinking about having a change on this site need to set something else on another site?

I certainly would not argue that this lets you ignore what's going on, internally or in the remote server. The failure cases and likelihood of those cases will change. This is really just a tool to make the mechanics easier. That doesn't make the system design easier, except that it might let you focus on the system and not get too bogged down in the mechanics.

# Ian Bicking