Roy Fielding’s latest post discusses the differences between software implementations, architectures, and architectural styles. Having spent the last few months rewriting DASe to adhere more closely to the REST architectural style, I have come to know the occasionally dizzying challenge of making good design decisions based on a set of principles operating at about 2 or 3 levels of abstraction above the nitty-gritty implementation that I am putting down in code. I had thought that DASe was fairly RESTful to begin with in its original design, but important RESTful constraints were NOT being followed, in fact. It has been an interesting adventure, to say the least, but I am as convinced as ever that the ultimate benefits will be worth it, both for DASe and for my own understanding of distributed information systems.
The architecture of DASe relies heavily on the Atom & AtomPub specifications, which I think is a pretty good base, since those specs are shot through with an understanding of and desire to capitalize on the principles of REST. When REST is discussed it is as likely as not in terms of HTTP and half again as likely to be in terms of Atom/AtomPub. So there’s much to be learned from some very intelligent folks on the subject. And frankly, when a design decision needs to be made, it can be difficult to bring abstract concepts down to the concrete and thus “what does Google do?” or “what does Amazon do?” is often a pretty good start. Same with Atom. Why not let the Atom spec design decisions flow back up into my design? So my database tables tend to have an “updated” column, and an “updated_by” column that map nicely to atom:updated and atom:author. And my primary domain classes generally have an “asAtom” method. It’s not so different, I think, from Mark Nottingham’s recent post about allowing the four principle HTTP verbs to inform his data model. Although ostensibly about getting “beyond” methods, it strikes as simply “convention-over-configuration” that says “OK — tight coupling with HTTP methods is fine” so we can move on to a level of abstraction up. Design is ALWAYS a balance, and I was completely mistaken when I assumed REST would be a cookbook of answers for the design challenges of web application architecture and design. But it does, I think, provide a framework for considering those decisions and an awareness of possible trade offs/benefits lurking when we choose one path over another.
The Roy Fielding post drew a comment/response from Sam Ruby, and that, a response from Roy stating “…but hypertext as the engine of hypermedia state is also about late binding of application alternatives that guide the client through whatever it is that we are trying to provide as a service.” I must have read it somewhere before (perhaps in the dissertation?), but I often use that phrase “late binding” in describing REST. It really is key — that the state of a representation need not be set until I choose to interact with it. And in my interaction with it, that state is bound (and thus usable & interesting to me) but there is no contract regarding that state. It can continue to grow and change and everything it links to can grow and change in their own time. I (a resource owner) am NOT bound by other’s interactions with the resource. Well, as a librarian, that is a compelling/revolutionary/subversive/threatening (not to mention terrifying) proposition! But it certainly does seem to offer incredible opportunity and captures much of the promise and messiness of information flow in the real world.
Comments are now closed.