Re: the necessity of describing responses in-band

More or less.

We didn't have remote/local data sets - everything was from server.
Unfortunately, we were implementing CQRS architecture, thus client received 
resources from server, used some extensions in the vocabulary to make a 
necessary transformation and sent back commands to the server. 
Transformation was made with JS SPARQL 1.0 implementation.
But in general, common was only the vocabulary. With proper API description 
we created views presenting data received from the server and could send 
them back to pointed endpoints. Templated links were heavily used.

Indeed it worked, changes made on the server's API were reflected in changed 
API description which caused changes in the views. But again, we did not use 
hypermedia controls, but sucked the API description in the initialization 
stage and used that to feed the client.

Regards

-----Oryginalna wiadomość----- 
From: Martynas Jusevičius
Sent: Wednesday, October 7, 2015 8:07 PM
To: Karol Szczepański
Cc: Hydra ; Kingsley Idehen
Subject: Re: the necessity of describing responses in-band

I don't think anyone really tried to understand my email titled
"Hypermedia acid test", but I think you are actually talking about the
same thing in this thread:
https://lists.w3.org/Archives/Public/public-declarative-apps/2015Apr/0000.html

Martynas
graphityhq.com

On Wed, Oct 7, 2015 at 7:34 PM, Karol Szczepański
<karol.szczepanski@gmail.com> wrote:
> Hi Kingsley
>
> I did create to one of the projects we had a prototype of a Hydra driven
> AngularJS client that built dynamically views from server side provided
> information.
>
> It was based on the API documentation part of Hydra rather than on
> on-the-fly discovered hypermedia controls. Unfortunately, Hydra is not 
> there
> yet to fully support this approach and we had to use few "extensions". I'm
> going to shed some more light on this in a separate post as it touches a
> private project of mine that actually struggles from similar issues.
>
> Regards
>
> Karol
>
> -----Oryginalna wiadomość----- From: Kingsley Idehen
> Sent: Wednesday, October 7, 2015 7:20 PM
> To: public-hydra@w3.org
> Subject: Re: the necessity of describing responses in-band
>
>
> On 10/6/15 8:17 AM, Ruben Verborgh wrote:
>>
>> Dear all,
>>
>> I've written a blog post that describes the necessity
>> of describing responses in-band:
>>     http://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/
>>
>> More than an argument for REST/hypermedia,
>> it's an explanation of _how_ we should realize that
>> with RDF-enabled representations.
>>
>> In this context, the Hydra Core Vocabulary is a major enabler,
>> because it lets us describe hypermedia controls in RDF.
>>
>> Best,
>>
>> Ruben
>
>
> Yes.
>
> Has anyone built an JS based client that leverages Hydra as a mechanism
> for building dynamic API exerciser consoles.
>
> [1] http://developers.facebook.com/tools/explorer  -- a nice example of
> the kind of client could be produced for any API described using terms
> from Hydra
> [2] http://petstore.swagger.io -- most APIs are described using Swagger
> these days, so Hydra-ting those will have dual benefits.
>
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>
>

Received on Wednesday, 7 October 2015 18:26:46 UTC