RE: Non-trivial trading flows with schema.org

Dietrich,
I'm thrilled to see you trying to implement Restbucks with Hydra. I'm excited to see your future posts on the topic.
I created a generic admin client to manage admin screens in a multi-tenant environment where each tenant could essentially define their own structures for each common type, such as User. I started by trying to use Hydra and eventually just morphed in my own hybrid format that took some ideas from Siren and Collection+Json. Hydra didn't provide all the information I needed. I will write up the gaps I found soon.
Andrew,

How far can you really get with a generic client  being 
practical for end users? I think that is an important question because 
the further you go with this the more you bake UI into the state 
exchange and the more you assume the resource knows the application 
state (which is not true in modern web applications).
It seems there is a tension between exchanging state and 
baking in user interface and workflows with the state. At what point do 
you accept UI is better expressed through other means?
When you come from the application development space you 
care more about  querying and updating resource state with your api 
(CRUD) and less about workflow/transitions since that is a UI concern 
and something you layer above the data access layer.
I again see embedding UI concerns into REST as the tail 
wagging the dog. When your app is composed of state from many different 
resources and services, it makes little sense for an endpoint to tell 
your app what to do or to prescribe a user interface workflow.
Despite my views I am still interested in how far you get with this and how the concerns are expressed in hydra. 
You routinely highlight a concern about inserting UI into the state exchange. I'm not sure I follow where you see UI here. I think you are confusing two different things: the controls and their visual representation. I'll assume you hold the opinion that markup such as <form> and <button> in HTML are UI elements. (Please correct me if I'm wrong.) I don't see things that way and often remove such elements and replace them with other components I want to use in my applications, e.g. replace a <table> with a grid that retrieves the table data and renders something visual. The markup is just instructional data to allow the browser and/or my app to render the desired application. The same can be true for other hypermedia formats.

I fully agree with you that UI is better expressed by other means. That doesn't mean the UI needs to know all the rules and workflows at the outset. I can't think of a production app I've built where my UI was built in such a way that it was intimately tied to my domain logic. The UIs with which I've typically worked usually consist of components that can be connected to perform a task when given some data, and I've usually mapped my domain data to match the component inputs. I don't see how hypermedia breaks this approach but merely provides a means of dynamically evolving how you might construct the UI. If anything I wish UI toolkits would provide more mechanisms for dynamically evolving the UI at runtime.

As to the "tail wagging the dog," I think it easy to see how state from many different resources can work well together. Apps that use components, each with their own backing resource, can surely follow their own workflows. If you can expose multiple forms on a web page, might each also refer to a different resource? Might each have different expectations they follow as a result of submitting a form? A media type that provides enough structure for a client to understand the interactions across workflows could provide instructions for managing larger, connected workflows. Of course, few except internal facing media types do this. If I recall correctly, Restbucks does this with its own media types.

Cheers,
Ryan