RE: Using Hydra in non linked data ReST services

Finally I've got some time to respond. But it was worth of waiting as you
Dietrich joined.

In general, I ... disagree with you. Well, somehow your way of putting
things feels similar to answering what was first - the egg or the chicken.
I'm not sure whether the HTML was first or the browser. Tim Berners Lee
presented it in 1990, first HTML spec was from 1993 by same guy thus we
don't know which one was first.

But that's not the point. While the WSDL comparison was the only one came
up my mind, you missunderstood me. My aim is to have a spec that will allow
me to describe an API so server will drive the client in a HATEOAS way and
I feel that currently available solutions are just failing in that area.
Proxy classes are just way of driving a client (and giving programmers a
good reason to be lazy).

Your comparison to HTML5 way is somehow wrong - indeed HTML5 provides very
basic description rules, but still, document is created on the server side,
thus it drives the client every possible way, including custom JavaScript
code. And leaves no disambiguities - this input field is in that very place
beacuse server said so and server knows what to do with it. Send it back
with minor change and server won't respond with 200 OK.

That's why I feel Hydra, and in general RDF syntax is the best way of doing
it as RDF itself has already a small degree of beeing a hypermedia with
it's URIs which can be dereference, and it can be interpreter, in contrast
to pure JSON, which is just a carier of data, a black box without any
meaning.

As for answering to Markus

>> - client had to know how to transform resources through SPIN constructors
>> into CQRS commands - we used those constructors in SPARQL on client-side
>> code to transform incoming entity into a valid CQRS command.
>Could you please elaborate a bit on this point?

In order to address a need that CQRS (in opposition to CRUD) architecture
defines - resources are modified by commands that generates events changing
the state of the resource (becoming a stream of events in time). When user
changes, i.e. a display name, it may happen that this single change was
elevated to a separate command-event pair, thus we had to know about that
fact in order to transform the incoming read-only resource and transform it
to a valid CQRS command which will change the state of the resource. That's
why we added an extra description instructing client that on change of a
predicate value, it should do something additional, i.e. run SPIN
function or constructor (described with SPARQL), etc.

>That's what hydra-java and the HydraBundle basically do
I wasn't aware of this - I'll need to dive into it, meaybe I'll learn more
on how to build hydra descriptions.

>Given that you compared current Web APIs to SOAP and feel confused by the
>need of knowing a JSON Schema: how is generating a class different from
>that? Isn't a class just a different realization of a schema?
Well, yes, but this class will be generated from the description.
Currently, if you send a JSON, client have the schema of that JSON usually
hardcoded. My aim is to provide a description of that schema so the client
can manipulate it wihtout a hardcoded logic.

Uff, I hope my targets are not fantasies and I'll be able to achieve them
richer with all the experience taken from discussions here.

Feel free to elaborate with those ideas as I'm keen to contribute more in
your work.

Regards
Karol