Hi Edgar,
Initially I started with transitions being represented as methods on the resource itself (because it mirrored a non-networked Object API), but I've since moved to your (a) version, of `client.action(...)`.
Two benefits:
* Keeping the transport information out of the resource itself ended up being a much nicer separation of concerns.
* It allows custom client instances to be used, and persist any information on transports and encodings there, rather than having to keep that information attached to the resource. For instance - you might want to customize the client to include some particular headers, to sign outgoing requests, or to accept some non-default set of encodings. Having all of that information bound to a `client` instance works rather nicely.
I found it an interesting little point in the progression of the design - having started with `resource,action(...)` and since moved to `client.action(resource, ...) it feels like the later more properly represents a explicit network interaction rather than naively trying to mimic an object interface.
Hope that helps some,
Tom