RE: Non-trivial trading flows with schema.org

On 22 Feb 2015 14:57, "Ryan Riley" <ryan.riley@panesofglass.org> wrote:
>
> 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.

No disagreement with your explanation of UI here. But when the data is
saying 'use this as a label, use this as a hint' and follow these 'labelled
operations' it has overstepped into a UI concern with the hydra console
being the use case.

Perhaps a pretty icon for menus will be the next addition to the spec so
generic clients like the hydra console can display meaningful options to
users pictographically, soon to be followed by keyboard shortcuts and
multi-touch gestures.

All of the labels hints and operations are there as a UI concern and it
really is a design smell.

>
> 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.

Again I do pretty much the same things as you do.  The important point
buried in there is "I can't think of a production app I've built where my
UI was tied to my domain logic."

That really is the point. The resource is telling the client the valid
transitions is pointless in the real production apps we all use. Hints and
labels and labelled  transitions (workflow) are solely there for a context
free 'what the server told me last' single service dumb client. HTML 5 does
a much better job than what hydra seems to be trying to do as it educates
the dumb browser how the payload can be maximally exploited intelligently.
Real world apps actually have a higher level context than what hydra can or
even should try to express so these things are just not relevant.

Why can't it just be about the semantics of the data and its relationships,
why does the data now try and provide things that are intended to be used
by a context free client in a UI dialogue with the user?

>
> 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.

I cannot see how a resource 'knows' anything about how that resource
representation is manifested or composed in a rich client or how that
client may orchestrate flows and operations across multiple resources and
service end points. So no I think its a completely lost cause and CRUD
semantics are about as far as things should go. I think CRUD is reasonable
to assume when dealing with resource representations, as opposed to
descriptive RPC like transitions/operations/UI-menus for use by dumb
context free clients like the hydra console.