Tie-in to HTTP in Hydra

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

Cheers,

Kjetil

Received on Friday, 30 May 2014 14:38:47 UTC