Re: Interesting discussion on Twitter

Hi Darrel,

> The <a> tag is simply a shortcut for what could be,
>  
>   <link rel=”anchor” href =””/>

The important difference between <a> and <link>
is that <a> is allowed to contain inline text.
Humans use this inline text to understand what the link means.
In the simple case <a href="?p=2">next page</a>
becomes <link rel="next" href="?p=2">

What RDF does in essence, is extending the "rel" vocabulary
through the use of specific predicates.
Hydra is (among other things) a vocabulary for such specific predicates.

> As I understand it, Hydra is providing a way for clients to know that something is a link without knowing what kind of link it is.

That's only a part of Hydra (and not a part I need).

Perhaps this is an important message for the list:
the different parts of Hydra should be made more clear.

> I tend to avoid trying to do things with links I don’t have any understanding of.

+1

> I think a limited amount of inline metadata can be useful for helping clients create HTTP requests.  For example, I think URI Templates are very useful. If there is significantly more metadata required then I tend to move that metadata out into its own resource as it tends to have a different lifetime than the data it is related to.

I wouldn't consider URI templates inline metadata.
These are hypermedia controls and they belong in-band!

> Adding inline interaction metadata to every affordance seems wasteful and redundant to me.

I don't get this. This is the famous hypermedia constraint.
What is hypermedia to you then?

> My comment about the risk of encouraging developers to build tightly coupled APIs is a concern that I have for all formats that are attempting to be API description languages.  The issues are nicely highlighted by this diagram http://www.hydra-cg.com/spec/latest/core/vocabulary.png

I agree partly on that; this is for me
not the most interesting part of Hydra (hypermedia controls are).

> building clients that make assumptions like -> when I dereference this identifier I will get this “class” of data back.

There's no problem with that if the assumption is communicated in-band.
Happens in "human" hypermedia all the time.

> The existence of “class” is encouraging developers to violate Fielding’s guidance that  “A REST API should never have “typed” resources

We should be careful not to be dogmatic here,
but rather try to understand the reasoning behind this.
Why did Fielding write it?
>> Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling
—http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Note that the typing here is used to explain what kind of thing you can expect,
not to assume a certain structure. That structure will be explicitly described in the message,
in particular how to interact with the resource (through hypermedia controls).
So no violation here.

Best,

Ruben

Received on Friday, 29 April 2016 08:37:20 UTC