W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

RE: Tie-in to HTTP in Hydra

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 3 Jun 2014 20:39:28 +0200
To: <public-hydra@w3.org>
Cc: "'Kjetil Kjernsmo'" <kjetil@kjernsmo.net>
Message-ID: <003701cf7f5b$284adca0$78e095e0$@gmx.net>
Hi Kjetil,

On Friday, May 30, 2014 4:38 PM, Kjetil Kjernsmo wrote:
> Since this is my first message to the Hydra WG, I'd like to present myself
> quickly: I've been around the semweb community since 1998, but started
most
> activities around 2005-ish. I've been a member of several W3C groups, WCL,
> POWDER, and SWEO (where I took the initiative to the Community Projects,
out
> of which the Linking Open Data project grew), and the SPARQL WG. In 2010,
I
> left the industry to pursue a Ph.D., which I'm still doing, on SPARQL
stuff.

Given your experience, I'm thrilled to have you on board. Good luck with
your PhD.


> While I love SPARQL, I think the vast majority of semweb application would
> be hypermedia-based, thus it is a prominent side-interest of mine. I had a
> paper about on the LAPIS 2012 workshop:
> http://folk.uio.no/kjekje/2012/lapis2012.xhtml
> and recently, I've started hacking a hypermedia application with a more
> narrow motivation:
> http://folk.uio.no/kjekje/projects/orienteering/byodnfyor.html

Great stuff!


> Anyway, to the point: I think Hydra is a really good start, but one thing
> that surprised me is that it has a pretty tight tie-in to HTTP. Since REST
> is expressedly *not* tied to HTTP, or any other protocol for that matter
it
> feels odd, and it also seems to be bad decision for pragmatic reasons too:
> My BYOD+FYOR scenario above doesn't only do HTTP, it does RTSP too (but it
> could do HTTP Live Streaming, MMS or a number of other protocols instead).

Hmm.... you are right. It certainly has been optimized for HTTP, but
wouldn't it be quite trivial to extend it to other protocols if needed?


> I was thinking about this when I wrote my LAPIS paper too, and I decided
> that the individuals I used should not nessarily look like HTTP verbs.
> Rather, they should make sense when read out as part of the interaction:
> Instead of saying POST, I would say what you would do when POSTing, i.e.
you
> would do an RDF Merge of the payload into the referenced resource, thus
> :mergedInto. PUT would do a replace, delete happens to be the same as the
> HTTP verb, though :-)

Right, that's exactly what operations are supposed to do. The method just
tells you how you can invoke that operation over HTTP. Nothing would stop us
from introducing other properties that would allow to invoke the same
operation over other protocols. The questions however is: is that really
something people are looking for? Does it make that much sense to send,
e.g., MMS or e-mails with JSON-LD/Turtle/whatever payloads? How would you
reference resources with those protocols?


> Then, what the client should do if the protocol happens to be HTTP, that's
> something the description of the the :mergedInto should express. I.e. the
> description of the API should not need to contain protocol implementation
> details, that's something the API should describe itself. And that extends
> beyond HTTP, when an API tells the client it may stream some video
resource,
> the individual is :play.

That's basically what an operation does. You might have an AddItem operation
which tells you that it can be invoked by POSTing. I think the difference is
that operations are somewhat self-contained whereas you would like to
strictly separate those two things. Is that correct?


> I think this is important to acheive independent evolution of protocols
and
> API description, and frankly, I think it would also make more sense for
> developers, they should think first and foremost about what the API is
> supposed to do for them, not how it happens to be implemented on some
> protocol.

Fully agree with your second point but I'm not so convinced about the first
one. The API description should tell me everything I need to know about an
API. That necessarily also includes protocol details such as the HTTP method
to use.


> The next step is then that the description of how something actually is
done
> on e.g. HTTP. That too possibly belongs in Hydra, but only when the top
> layer has been established. IMHO. ;-)

So, let's try to make this a bit more concrete. What do you think would need
to be changed in Hydra to make "the top layer" more established?



--
Markus Lanthaler
@markuslanthaler
Received on Tuesday, 3 June 2014 18:40:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC