RE: Using Hydra in non linked data ReST services

On 29 Jan 2015 at 14:18, karol.szczepanski@gmail.com wrote:
> 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

Yes, this is a limitation we need to address.

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

Could you please elaborate a bit on this point?


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

OK. What do those additional actions look like? Data validation? Something
else? Btw. are you aware of

  http://decoupledcms.org/technology.html

Seems to be quite related.


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

Thanks for sharing your thoughts.


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

That's what hydra-java and the HydraBundle basically do


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

Given that you compared current Web APIs to SOAP and feel confused by the
need of knowing a JSON Schema: how is generating a class different from
that? Isn't a class just a different realization of a schema?


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

Fantastic. Please let us know as soon as it is online.


> Feel free to share your feelings and ideas on how it might be doable with
> hydra.

I surely will :-)


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 29 January 2015 23:06:25 UTC