Re: Relationship between filter properties and hydra:supportedProperty (was Re: Filters as views (ISSUE-45))

Am 11.02.2016 um 11:51 schrieb Tomasz Pluskiewicz:
> February 11 2016 11:28 AM, "Maik Riechert" <maik.riechert@arcor.de> wrote:
>> You mean @type instead of @id for the views I guess.
>>
> Of course :).
>
>> I guess the question is whether it would be advantageous to define these
>> details also individually, because otherwise you will end up creating
>> a bunch of types for various APIs and you would essentially end up with
>> hard-coded APIs again
> These template types would be just as hardcoded as link types are. It would be necessary to include some description in the ApiDocumentation of course and we may decide on the details there. Other than that the client mustn't be hardcoded at all. Client unaware of precise meaning of "ExactSensorSearch" or "AreaSensorSearch" would still be able to provide UI and build valid view URLs. A simplest solution would involve a human-readable description so that the user can choose the view he's interested in. In such case the template type is not required at all:
>
> {
> "@id": "/sensors",
> "view": [
> {
> "@type": "ViewTemplate",
> "template": "/sensors/exact{?lat,lon}",
> "description": "Find sensors at precise location"
> },
> {
> "@type": "ViewTemplate",
> "template": "/sensors/around{?lat,lon,radius}",
> "description": "Find sensors in surrounding area"
> }
> ]
> }
>
> It is important to decide whether we're talking about user agents or autonomous clients. The latter would be great but it's been effectively a holy grail. Haven't service discoverability attempts to date all failed miserably? I'm afraid that Hydra will follow such path if we're too ambitious.
I'm all about autonomous clients. The problem I have with specific view 
template types is that I may want to combine properties of different 
APIs, for example properties from OpenSearch Geo & Time and... a 
property that filters by publisher name. Clients that understand these 
things individually would be clever enough to use them together.

My point was just that types will not cut it in my opinion. I'm not 
saying that Hydra should focus on solving this problem once and for all. 
In my own project I apply some kind of fuzzy logic based on what 
properties I find in a template, e.g. "Ok, I found a radius, that means 
I can filter by a circle, which means I also need a lat and lon, and 
yay, I found that as well, all good". Something like that.

Cheers
Maik

Received on Thursday, 11 February 2016 12:08:11 UTC