Re: Filters as views (ISSUE-45)

2016-02-22 20:00 GMT+01:00 Karol Szczepański <karol.szczepanski@gmail.com>:

> Implementation is quite simple. Server builds a complete API documentation
> based on reflection and other pieces of information (C#). Resulting Iri
> template would look like this:
> http://my.api/entry-point/products{?$filter,$skip,$top}
> Variable mapping uses a fake OData namespace (as there is none suitable for
> now): http://docs.oasis-open.org/odata/odata/v4.0/$filter.

Nice.

> I could use http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398094
> as the reference, which is actual one leading to $filter description, but it
> looks ugly.

Indeed. How about defining an alias in purl.org and using the purl
alias instead?

> Client side have several components which are checked against each mapping
> and if it responds positively it is allowed to process passed information
> (current filter settings, paging, etc.) and generates an expression. This
> way I can have several components which may "understand" various mappings.
> If no components is applicable, it is just left untouched. Iri template
> allows the value to be optional, thus it will miss that very variable value.

Could you please post examples of how this looks on the wiki so it can
be discussed further and so people understand just exactly how OData
can be used in Hydra? I think that's unclear for a lot of people,
perhaps me included. :-)

2016-02-24 9:45 GMT+01:00 Ruben Verborgh <ruben.verborgh@ugent.be>:

> Perhaps we still need to draft a couple of alternative directions.
> Just to see if they might be easier.

I agree, which is why I'd really appreciate if Karol could contribute
his OData implementation on the wiki.

> EQUALS is not enough for everything; but it is a good default.
> The mechanism should be extensible (for instance, freeTextQuery).

I think it's unwise for Hydra to have any querying capability at all
built in. Instead, it should be really easy to plug in OData, SPARQL
and other extrenal query langauges. Anything we try to specify in
Hydra is not going to be sufficient for anything but the simplest and
most banal cases and I'd argue won't be anywhere near the 80/20 rule
that often governs decisions on whether to include something like this
in a specification or not.

> A generic notion of expressions should be sufficient.

As long as it's pluggable, I agree.

> The core could define a couple of basic operators (AND / EQUALS / …);

It could, but hopefully Hydra leaves the whole business domain of
querying to other langauges, since these already exist and do a much
better job at it than what we can expect to do in the Hydra
specification.

Now please don't misunderstand me. I'm not saying this because I have
bad thoughts about anyone in this CG, but because Hydra is not (or
imho; should not be) primarily about querying, but about hypermedia
controls and affordance.

So investing the amount of time required to specify a query language
that will cover 80% of the cases where querying is going to be
implemented, is simply not something I think this CG should be
focusing on. We have enough to do that lies within Hydra's problem
domain already, don't we?

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Wednesday, 24 February 2016 13:55:11 UTC