Re: Filters as views (ISSUE-45)

Hi Dietrich,

> In my suggestion
> 
> "urlSyntax": "tpf url syntax uri"
> 
> was not supposed to say it is a tpf api, only that the URI syntax is the one described by tpf.

I understand—however, if that URI would indeed be specific to the TPF API, then it would effectively be a “magic constant” and we might as well just simply say “it's a TPF API”. When describing APIs, one such magic constant is enough to break access for any client that is not specifically programmed for an API.

> We could also call it "simple hydra query syntax", describe it in the hydra spec and use a hydra URI for it, for that allows you to describe tpf in terms of hydra and not the other way around.

That's what I'm after indeed.

> You certainly agree that self-descriptive messages as a ReST constraint always implied that certain external conventions can be invoked as part of the self-description, e.g. by mime-types or profiles, so we would absolutely be self-describing.

Certainly!
My concern here is about reusability of the pieces.
TPF itself is a specific API, but the principles are so generic we should capture the semantics on a higher level.

> The difference between hydra:filter and this suggestion is really only that urlSyntax allows to plug in external url syntaxes

The ability to plug in is definitely a necessity; but this should only be needed for complex cases IMHO.

> whereas :filter would have been restricted to tpf queries.

Not really. There had been propositions to also allow different syntaxes for :filter.

(For the sake of comparison, I could write out an alternative with :filter, similar to what Markus did.)

> BTW odata and opensearch are not really a good fit for uritemplates. I like Tomasz's idea to have pluggable filtering mechanisms.

Pluggable is fine; but there should be sensible defaults out of the box.

> Can you line out a use case where the machine requires a detailed, case by case description of the query syntax with allowed comparison operators, allowed usage of AND and OR etc., where no human is involved?

Yes: I envision a client that is able to query any API with a uniform query language.

But that's not the main reason why I'm pursuing this. My main reason is that the necessity for magic constants voids most of the reasons why we would describe APIs for machines in the first place.

Best,

Ruben

Received on Thursday, 18 February 2016 20:08:47 UTC