RE: Using Hydra in non linked data ReST services

Hi Karol,

On Monday, January 26, 2015 6:45 PM, Karol Szczepański wrote:
> My name is Karol Szczepański and I've recently joined the Hydra
> community, but I've got already some experiences with using it in real
> life.

Welcome on board! Great to hear you already used Hydra


> These experiences are around describing linked data compliant ReST
> service where client-server bi-directional communication was utilizing
> RDF serializations (usually JSON-LD).

Cool. What kind of service is it? How does the server talk back to the client?


> Recently, unhappy with how frameworks available for programmers
> exposes ReST services, I've started thinking and working on something

I would be quite interested in hearing why you personally were unhappy with current frameworks? Unhappy on the server side, the client side, or both?


> that would allow programmers build ReST services more easy and by ReST
> I mean real ReST where a common ground for both client and server is
> HTTP protocol and not a blackbox named JavaScript (or JSON to be
> specific) wrapped around few HTTP features (like verbs).
> 
> My thoughts came quickly to Hydra as the framework for describing the
> ReST services, which rises few questions.
> 
> First of all, the Hydra spec mentions about linked-data services.
> Unfortunately, this paradigm seems to be at the beginning of it's path
> and still plenty of services are not RDF aware. This rises a question

Right


> whether is it considered to have Hydra capable of describing these
> services as well. With the current state I find it quite difficult to

The question is: describing them at what level? Without having to change them at all?


> express details like media types allowed by operations.. This actually
> might be useful for RDF aware services where it is required to send
> both RDF and binary blob. I've used the file API in latest JavaScript
> specs to transform files into an xsd:base64Binary, but that felt
> unnatural and multipart media type seemed a better approach.

Yes, this is a shortcoming we definitely need to address sooner or later. It is being tracked as ISSUE-22 [1]


> It seems also difficult to get the client know i.e. when it can send a
> single object/RDF statement, multiple ones or list of them. >From RDF
> point of view it is OK to have i.e. multiple statements with same
> predicate, but probably most of you won't like to see rdf:List of
> rdf:Lists of rdf:Lists instead, and these are pretty valid from the
> RDF point of view.

Right. We need to get much more expressive on the "expects" side. The new RDF Data Shapes WG looks quite promising but it is too early to tell for sure... and I have to catch up with their recent work.


> What are your thoughs on this matter, as I think it might be an
> interesting feature of Hydra to describe both linked data and classic
> services alike.

We are not focusing on being able to describe arbitrary existing services but we definitely need to be expressive enough to describe the functionality/interface you outline above. If you have a concrete API that is simple enough to be used as a case study it would help a lot. We could use it to analyze what's currently missing in Hydra to fully describe it and also compare various designs.


[1] https://github.com/HydraCG/Specifications/issues/22



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 27 January 2015 21:47:44 UTC