choosing Action-Types for concrete implementation

Dear all,

I've been following this working group for quite some time now and really appreciate the work and the progress that you've made! Hydra opens up a whole new range of possibilities that weren't accessible before. That's the reason why I experimented with my own client server prototype that generates a server and a client from Json-ld data dynamically. With that it was then possible to take a declarative approach to creating both the frontend and the backend, e.g. loading the entire schema.org data structure, similarly loading hydra's.

For the back-end I am working on making it possible to create an Entrypoint's behaviour based on a single hydra API documentation. However, I've realised that some behaviour is missing or that a clear definition of some behaviour is missing, although it is implicit for human readers. For example when POSTing to a collection, a type I've seen used is schema.org/AddAction, for GET hydra:operation. For PUTting to a single Object I thought about schema.org/ReplaceAction, but that would force all requests to be really big, since my backend supports all fields of a schema.org-Type. Alternatively I thought about POSTing to a single Object and add/replace only the fields of that particular request. However, the description of schema.org/UpdateAction is too vague for that particular update strategy.

For my generic approach I would like to have clarity about the behaviour that is to be expected behind a URI. Do you guys have any hints on how to choose the correct types or is it just me who is implementing behaviour behind those types directly?

For the frontend there is a similar situation where I am using a combination of visual and data access components that in turn can make up a new type. Each component declares what schema.org-Types it can handle (or define a new signature, for a combined type). In order to make the frontend similarly generatable as the backend, the backend and frontend behaviour for action types should be similar, so that the APIDocumentation acts as a kind of "contract".

What is your take on behaviour behind schema.org-defined Action-types? Is there some kind of reference I can refer to or is their functional implementation still open?

I've attached an image of the current state of development. It's a screenshot of the designer showing orchestration of visual and data access components for the frontend.

Best wishes to you all and keep up the great work!

Jonathan