Re: Tie-in to HTTP in Hydra

On 30 May 2014 16:37, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:

> Dear all,
>
> 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.
>
> 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
>
> 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).
>
> 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 :-)
>
> 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.
>
> 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.
>
> 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. ;-)
>

+1


>
> Cheers,
>
> Kjetil
>
>