Re: Hydra and the uniform interface

On Thu, Dec 5, 2013 at 3:38 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
>> > This tells a client that when it encounter a triple like
>> >
>> >   <> :order </order> .
>> >
>> > It can POST a schema:Product to /order to order it.
>>
>> Right, that's consistent with my view (AFAICT) and exactly how I'd
>> declare an order path. But the HTTP 200 response that results from
>> that potential interaction being followed still just means "The POST
>> succeeded" and so is not an "operation" in the sense that most people
>> understand. If the 200 meant "the product was ordered" - which I
>> believe is what you think is necessary and support with Hydra
>> operations - then you couldn't do the implementation-substitution
>> manoeuvre we talked about before because the other implementation's
>> 200 responses will mean the former, not the latter.
>
> And if the new implementation would advertise the same Hydra API
> documentation? If I understand you correctly, you say that HTTP doesn't
> define any contract apart "200 POST succeeded". I think it's possible to add
> more semantics on top of this HTTP contract.
>
> 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.

>
> If two implementations advertise the same contract, they can be substituted.
> If not, they can't.

But that's the whole point of the uniform interface! What you're
describing isn't REST, Markus.

> 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.

>> > Operations decouple the "functional semantics" from link relations so
>> > that you can use them to describe link relations or operations allowed
>> > on resources (or resource classes) themselves.
>> >
>> > I believe we agree already and that it's just the terminology which
>> > causes some confusion. But maybe I'm also wrong and you have
>> > something else in mind. If so, I think the easiest way forward is to
>> > explain it based on a concrete example.
>>
>> I hope we agree, but don't think we do. I'm not 100% sure that we
>> disagree on that point above though. Hopefully so, but if not, I'm at
>> a loss to explain why you'd ask "Do you really think POST/PUT etc. are
>> enough?"
>
> Could you POST a simple descriptive example illustrating the points you
> think we disagree on?

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.

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?)

Good luck,

Received on Friday, 6 December 2013 20:59:44 UTC