RE: First release of hydra-java for spring-hateoas in Maven central

Am 13. Oktober 2014 16:14:25 schrieb "Markus Lanthaler" 
<markus.lanthaler@gmx.net>:

> On 6 Okt 2014 at 18:32, Dietrich Schulten wrote:
> > Am 6. Oktober 2014 13:08:48 schrieb "Markus Lanthaler":
> >> On 2 Okt 2014 at 01:18, Dietrich Schulten wrote:
> >>> Am 1. Oktober 2014 17:48:30 schrieb "Markus Lanthaler":
> >
> >> It is very little work to require to add an explicit
> >> mapping to schema.org at the package level but "forces" developers
> >> to think about this mapping.
> >
> > OTOH people will first have to learn how to annotate packages and ask
> > questions about that. I'll look into ways to warn developers about
> > undefined attributes, I promise [issue #5].
>
> Well, yeah. They would need to learn about that but it's pretty easy:
> include an example in the README that people can copy and paste :-) IMO
> people really need to understand that there is a mapping to make use of this
> library... but obviously you are the one to decide that.

Another strong point for you: validation tooling needs to know what to 
validate as json-ld. So I think from the next release it will be necessary 
to define some context for beans in order to get json-ld responses :-)

> >>> It seems, schema.org is a bit ahead at the moment. I find
> >>> PropertyValueSpecification very expressive, it tells the client exactly
> >>> what it should send, in place, very much like an HTML form, see [1]. No
> >>
> >> Yep, it defines more constraints ATM. I'm not that much of a fan of the
> >> annotation model it uses (<property>-input / <property>-output) though.
> >
> > Why is that?
>
> Because it kind of defines new properties etc. on the fly whose semantics
> depend on its IRI structure:
>   http://schema.org/name -> http://schema.org/name-input
>

I see, name-input is of course identified as http://schema.org/name-input 
in the context. Possible values however would be defined on schema:name, 
not on schema:name-input.

They *can* express a request template which does not depend on the IRI 
structure, but which describes a request body.

But from their review POST example it also seems that a request body sent 
to an entry point has to be an Action subclass[1]. If that is in fact a 
reqirement, it would be quite unusual from a restful point of view, and 
makes it difficult to use a potentialAction for an existing ReST service 
which does not expect Action request bodies.

I am really after an equivalent to html forms which allows me to tell the 
client how the request body to a POST should look like, possibly without 
forcing it to download rdf descriptions for all request body properties to 
learn about the expected values.


>
> > Do you plan similar input constraints in hydra? Or is there a
>
> Yes, in some form or another. Currently we just have readable/writeable but
> nothing prevents us from adding more.
>

I'll write an issue :-)

>
> > better way in json-ld? With my Javascript background, I find the html
> style
> > very appealing, clients can blindly apply them in a browser.
>
> Applying things "blindly" is always a *huge* security risk.

Granted, and I knew right after sending that the word blindly was not 
chosen wisely :-) Well, here I would apply the server's input constraints 
without having to parse them one by one. If I did parse them and apply them 
to the DOM one by one, I would gain no security advantage, would I?

Best regards
Dietrich

[1] http://lists.w3.org/Archives/Public/public-vocabs/2014Oct/0032.html

Received on Monday, 13 October 2014 16:01:26 UTC