RE: Using Hydra in non linked data ReST services

Hi Markus

> Cool. What kind of service is it? How does the server talk back to the
client?
My (our, as we worked as a team on that project) experiences with Hydra were
related to a semantic CMS project. Aim was to create components that would
allow us to setup a CMS based on pure semantic technologies. This meant that
back-office would communicate via RDF serializations, thus our client-side
app had to comply. We had an idea of server driving the client with HATEOAS
paradigm and Hydra was the carrier of the hypermedia data. Unfortunately, we
had to extend hydra due to:
- client had to be instructed on business rules each RDF resource had, i.e.
this predicate should appear once, multiple times or should be an ordered
list
- client had to know how to transform resources through SPIN constructors
into CQRS commands - we used those constructors in SPARQL on client-side
code to transform incoming entity into a valid CQRS command.
- client had to know when it should transform resources - we created
something similar to "onchange" events and when a value of a predicate has
changed client knew that some additional action needs to take place before
sending back the resource

> 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?
As for my unhappiness with framework is the fact that their ReSTfulness is
comparable to those focused on SOAP. Most of them are so focused on nice
URLs and JSON serialization, that makes me feel somehow confused as client
still have to know the JSON schema. Only difference compared to SOAP is the
fact that it sometimes uses GET and sometimes POST/PUT/DELETE. And when you
want to play with the topic in most ReSTfull way, it takes time and
sometimes you have to bent those framework to your needs.

 > The question is: describing them at what level? Without having to change
them at all?
In general, my aim is to have a vocabulary, that would allow me to create a
framework that would automatically generate ReST API documentation, which
then can be used either by a generic client or by a proxy class generators,
i.e. in C#, so the programmers won't have to focus on communication details
but rather on data and processes. Something WSDL-like for ReST, and I feel
RDF is the best carrier of these details. In order to achieve that, I'll
need details both extending and redundant to what HTTP gives, i.e.:
- allowed content-types; Linked Data Platform mentions about a header
Accept-Post and Accept-Patch, but taking these details "offline" into a
single api documentation seems more promising
- allowed methods (this already exists)
- allowed data structures (single values, multiple values, lists,
dictionaries?)
- uri creation rules (this also exists, thus I'm not sure how to use
IriTemplates :))

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

I'm quite close to have a working alfa of my "framework", and once I'm happy
with it I'll try to share it on github (or other public git).
Feel free to share your feelings and ideas on how it might be doable with
hydra.

Karol Szczepański

Received on Thursday, 29 January 2015 13:18:59 UTC