RE: Hydra and the uniform interface

Hi Mark,

Sorry for the delay

On Friday, December 06, 2013 9:59 PM, Mark Baker wrote:
> On Thu, Dec 5, 2013 at 3:38 PM, Markus Lanthaler wrote:
> > You can either define them in a media type specification and expose
> > them by typing the requests/responses with that media type, 
> > as e.g. AtomPub does, or
> > use some other mechanism. Hydra is an attempt to make these contracts
> > machine-readable and discoverable at runtime.
> 
> I understand the objective, as I shared it when I developed RDF Forms
> over 10 years ago. It too was type based like Hydra (something I've
> mentioned I wouldn't do again). But it made no attempt to change the
> HTTP contract, because it didn't need to.

I'm trying to understand why you think Hydra changes the HTTP contract but
I'm afraid I still can't follow you.


[...]
> > The same applies to an AtomPub server and a WebDAV
> > server IMO. Both speak HTTP and adhere to the contract defined by
> > HTTP but they also extend it (or specialize it if you want). I
> > think we agree that you can't substitute an AtomPub server with
> > a WebDAV one.
> 
> tldr; no, we don't agree.
> 
> That's a complicated example though. On one hand, AtomPub and WebDAV
> are competitive and incompatible in significant ways. But on the other
> hand, the point of substitution is not to ensure implementation
> consistency - in this case, that clients would be able to interop
> perfectly with each server implementation - but exactly the opposite,
> to modify system functionality by using new and/or different
> components in a layered architecture. For example, by sticking a cache
> in front of a Web server; same contract, different overall behaviour.

OK, then at least we've found an example worth a closer look. Why do you
think that AtomPub and WebDAV don't change the HTTP contract but Hydra does?


[...]
> I'm still not entirely sure what points we disagree upon. We've got
> that one above, for sure, but I'm not sure what might be gained from
> deep diving on it. I suspect there's also disagreement about the
> generic meaning of responses (as previously mentioned) and probably
> the roles of predicates, types, and their relationship to the uniform
> interface. But I don't know. Perhaps I could motivate that
> conversation with a suggested edit to the spec (in case it wasn't
> clear already what I would like :), so here goes ...
> 
> Remove everything including and after "While links are enough to build
> read-only Web APIs" in sec 4.1.

Wow. I didn't expect something like this. So you are saying that all that's
missing is a concept to define a link, i.e., hydra:Link? How would an
application know how to use such a link? Without any further information,
the only solution I see is to hardcode it into a client.


> But perhaps that will just bring up the same issues we're already
> discussing. If so, I'm not sure that there's anything more I can add
> to this conversation, so if I haven't convinced you yet, I probably
> won't be able to. Perhaps somebody else would like to take that up
> (Stu?)

Well, I'm still trying to understand you. I'm not trying to convince you
with my statements/question but find out what you are trying to say to I
don't seem to understand. Given your experience I'm of course very
interested in your thoughts. It's just that I still struggle understanding
them. Thanks for taking the time to respond to my mails. Much appreciated.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 11 December 2013 22:38:11 UTC