Re: Tie-in to HTTP in Hydra

Hello and sorry for my hit-and-run email, things are rather busy around 
here.

On Tuesday 3. June 2014 20.39.28 Markus Lanthaler wrote:
> Given your experience, I'm thrilled to have you on board. Good luck with
> your PhD.

Thanks a lot!


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

Well, that's what I would want to know, and I don't think we know before 
it's done. :-) So, that's why I think the Hydra group should take that upon 
their shoulders. And I think a description of how you would do it for more 
protocols would also be an important deliverable.


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

Right, good question! 

So, the thing is that I don't think the payload has to go across the 
protocol to be useful hypermedia! :-)

Since the dawn of RDF, you could just stuff any triples in a "file" on a 
webserver, and the URL of that "file" wouldn't need to appear in the RDF at 
all. This newfangled thing that that URL should be a URI in a subject, or a 
concise bounded description or something, that's a restriction that may be 
useful in a Linked Data scenerio, but it is not a general requirement. :-)
Moreover, nowadays, that URL can easily be thought of as a graph name. Or 
the URI of a hydra:Collection, or something, so it is not anymore 
constrained to files in a filesystem either, quad stores can easily 
accomodate.

So, that's what I did in the implementation of my one-off RTSP scenario:
https://github.com/kjetilk/Sport-Orienteering-
FYOR/blob/master/lib/Sport/Orienteering/FYOR.pm#L123
(please bear over with the code quality here, it was a one-off hack I wrote 
in a week). What it does is that for the cameras, that has rtsp-URLs in 
their subjects and thus isn't terribly good at carrying RDF payload (though 
I suppose they could stream RDF statements...?), I retrieve all triples with 
the graph name that matches the Request-URI using HTTP.

And I'll claim that this is hypermedia is good as anything. :-)


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

OK, so taking this questions as one, as I am not totally sure what the 
requirements are based on what I want. :-)

I think it is important to separate the concern of the library developer and 
the application developer. The library developer need to be concerned about 
the protocol details, such as the verb to use. The application developer 
should be concerned about that to a much lesser degree. Ideally, I think, 
they should just need to use the library and be able to use it from their 
angle, that is, what the API is supposed to do for them, not how it is 
implemented. But then, this ideal, I don't know if it is reasonable or even 
desireable, we won't know that before it is tried. :-)


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

Mmmmm, perhaps modularize it...? Like, having something that is just an API 
description module ("top level") and then an HTTP module, and then pick 
another protocol and use that to learn what changes are needed in the top 
level to accomodate for more protocols?

Cheers,

Kjetil

Received on Sunday, 15 June 2014 10:11:56 UTC