Re: Client POC

Hi Markus

Thanks for your input. Deliberating more...

>> In general it's mostly about introducing RDF lists and resource 
>> collections
>> (previously only literals were supported).
>>
>> To summarize:
>>
>> - the API documentation is still not fully hydra compliant, i.e. I'm 
>> still
>> hesitate to use collections - I will have different data models for data
>> types and operations (operation may return Collection, but range for a
>> property isn't supposed to be a Collection - I think). Actually I was
>Why not?

I feel it's unnatural to expect a Hydra hypermedia related types in classic 
RDFs/OWLish constructs.

>> wondering how it should be implemented correctly - if the API 
>> documentation
>> says that an operation returns a collection, should I put it also in the
>> operation response?
>Yes

That's what I was aftaid of...

>> I prefer not to have these elements in the data payload
>> as it would mean additional graph processing to get rid of any non data
>> related resources before presenting
>Not sure I follow. Is the question whether a response should return a 
>collection when an operation's description says that it returns a 
>collection? The answer would be yes. If you don't >want to return a 
>collection, why would you tell a client that you do?

All I want to achieve is a data payload free of hypermedia controls - with 
data and hypermedia controls mixed altogether, I'll need to put with my 
collection members also a hydra:Collection resource forcing me to filter it 
out from the response so I can use it to bind the view with data, i.e.:
GET /my-collection ->
<> a hydra:Collection;
    hydra:member </1>, </2>, </3>.
</1> rdfs:label "Resource 1".
</2> rdfs:label "Resource 2".
</3> rdfs:label "Resource 3".

With the <> resource, I cannot use the response "as-is" - I'll have to 
sanitize before or at view binding process which complicates code.
I'd like to have both - API doc saying that client should expect a 
collection, but I shouldn't be forced to have this component in the main 
data payload. Please rember, that I'm also trying to have oldschool plain 
JSON based API in mind simultanously with RDF APIs. So far I'm able to have 
same code able to run both cases on client and server side!

>> - Hydra is somehow ignorant when it comes to RDF lists - I'm denoting 
>> that
>> an operation or a property is an RDF list by using an OWL'ish "strongly
>> typed" RDF list inherited class (some restrictions etc.). I acknowledge 
>> RDF
>> lists as somehow a separate beings as from RDF point of view it's a
>> different beast
>Sure. Hydra is "ignorant" about a lot of things. What would you like it to 
>support?
Well, don't know honestly. Currently I use those construct I described to 
enable/disable collection members sorting (only for lists). I don't want the 
client to be surprised with an rdf:List construct once the response is 
received. Those constructs I used are somehow OK, but not very 
straight-forward .

>> - There are few things missing that might cope in handy; i.e. hot to 
>> denote
>> a display name property
>hydra:title?
Maybe I was not clear enough about this. I'm trying to achieve a feature of 
saying on the API documentation level which property/properties of the 
received resource (i.e. in the collection) should be used as a "display 
name". Imagine, that the client wan't to download a collection of members 
and display then i.e. with a drop-down list. I cannot show resource Uri's as 
these would be meaningles for the end-user. I'd like to build a construct on 
the API level which would instruct on how to "format" such a display name 
either with a single pointed property, or i.e. a format string using several 
properties (i.e. person's first and last names separated by space).
I feel that hydra:title is not what should be used here - it's supposed to 
describe hypermedia controls rather than data. Actually, I'm not sure 
whether this kind of features should be in the core of Hydra - maybe there 
is something else I could use.

>> PS. Markus, is your PHP JSON-LD processor fixed? It didn't accept @type 
>> in
>> literals and it prevents me from testing my API documentation generator 
>> with
>> your console.
>Yes, that should have been fixed for a while. Let me know if it still 
>doesn't work.
Superb, I'll have to return back to tests though. Thanks!

Best regards

Karol

Received on Monday, 8 February 2016 20:47:51 UTC