Day 1 of
WWW2010 is complete. I spent the day in the
WS-REST Workshop. The day, for me, started out a bit sketchy.
Sam's talk was ridiculously interesting, but only tangentially related to REST. Most of the others were solid, predictable and safe. The couple presentations that did approach the edge of our current understanding of REST were, well, bizarre and, arguably, an impedance mismatch for the style itself.
Federico's talk (no slides) was pretty interesting. He suggested the need to describe and communicate new styles that were based on REST but not exactly REST. More generally, a practical model for visualizing and understanding architecture design rationale. He had a modeling tool (i forget the name) that manages a graph of constraint, rationale, and properties (or somesuch). This is somewhat analogous to the styles->properties mapping in the dissertation itself but instead of talking about styles, talking about the constraints directly. For other reasons, I've come to talk directly about constraints instead of REST too lately. It turns out that frameworks facilitate getting REST wrong just as much as they do getting it right, so instead of talking about a squishy style, I've found it more useful to enumerate the constraints explicitly. Having a modeling approach to reason about all this would be pretty useful.
Being hosted at a conference dominated by academia, potential "research areas" seemed a key focus. Some thoughts that I had during the day...
1) It seems that we need more research on getting from style to architecture. Practically, we end up with an unreasonable delta between where the style leaves off and additional constraints of the architecture. We need a framework for defining, sharing, and reasoning about those extended constraints. This doesn't get highlighted very often primarily because the folks that talk about REST do so from the perspective of a single service rather than an
architecture group constraining a set of services across an enterprise? For example, suppose a particular architectural style gives us 6 constraints and a specific architecture has 3 additional constraints. Those 3 constraints are, typically, hidden as implementation details but they should be highlighted and reasoned about in the same way that the style itself was.
2) Someone mentioned the need for the sales pitch for REST style. In other words, if a simple RPC-style solution could be hacked together in half the time, why spend time designing media types, changing the paradigm, etc. ? Intuitively, it seems that the answer is the system properties evoked by the REST style, but maybe that doesn't resonate with managers, etc.?
3) Media type design. Someone mentioned this too, but it's clearly a theme in the RESTful world. It seems that we have collectively grokked what Roy has given us in his dissertation so far and are all collectively struggling with the variety of media type issues. When to pick one over another; when to create your own; how to create your own; json:link types missing; when to use specific vs. generic representation control data (e.g. /xml or /myformat+xml); etc.
4) Link qualifications. Link relations are clearly the way to assert the semantics of the relationship between the "current" resource and some "target" resource. I think we need some clear way to qualify the "target" resource independent of it's relation to the current. Perhaps there isn't a particularly important link relation but you want to assert some link selection criteria anyway.
5) Transactions, of course, got token mention.
Mike(i think) mentioned them as the "third rail" of REST:) I dunno, I don't do services on the wild internet so maybe it's a concern, but I got a gut feeling that we've got some problem-solution force-fit going on here. I see the same thing with messaging too - I haven't seen a lot of valid needs for a composite REST/Publish-Subscribe Style. I like REST. A lot. But there are plenty of other valid architectural styles appropriate to other problem domains.
6) Similar to #1 above where there needs to be a macro discussion of REST for the enterprise, I wonder if there's a place for REST style in the micro. It seems like the same REST principles could be applied to micro application architecture. Something like the Actor model of immutable message passing.
Anyway, my rough notes of Day 1 as I understood it...
