Personally, I never understood how overgrowth can be a good thing: 12,000 APIs means 12,000 different ways of engaging in machine-to-machine interaction. -- Ruben VerborghGood to know that other people have tread this ground before I start ranting.
I was introduced to Robert Zubek's needs based ai paper recently, which returned my thinking to a problem I've struggled with in understanding hypermedia.
To wit, what does it mean to have a client that is decoupled from the server?
We know from the experience of the web that hypermedia controls are a big part of it -- allowing the server to communicate the available affordances to the client means that the server can change the how as it likes, and the client doesn't need to survey the possibility space, but can instead limit itself to the immediately relevant set.
So we take a look at a hypermedia driven example -- for instance, Jim Webber's RESTBucks. The domain application protocol looks something like this:
You can have your coffee any way you like, as long as it's black.In either case, if the client is focused on following the protocol, it's screwed. The trap is the same client/server coupling we fled to hypermedia to escape. Instead, we should be thinking in terms of multiple protocols -- if RESTBucks happens to be offering a take-free-coffee endpoint today, clients that understand how to negotiate it should be able to understand it.
What I'm beginning to see is that there is a choice; instead of teaching a client that a specific extended protocol will produce a goal, we may be able decompose the protocol into a number of different pieces that can be composed to reach a goal -- if we can manage to describe the affordances in a way that the client can understand, then we can start building complicated protocols out of simpler ones and glue.
Maybe -- we still need a client that can snap together the legos in the right order.
