Ian Bicking: the old part of his blog

Restful transactions comment 000

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.

Comment on Re: RESTful transactions (a speculation)
by Ian Bicking