Re: Filters as views (ISSUE-45)

Dear all,

We're making things too complicated.
This thread is not about describing every little detail,
but about deriving views of collections.

>>> "urlSyntax": ... one of TPF, opensearch, odata ...
>> 
>> Then we lose the self-descriptiveness and we're back to square one.
>> 
> 
> No, we're not. Hydra already provides more API description facilities than any other hypermedia media type I know.

I need something more than an IRI saying "this is a TPF API", to describe a TPF API.
Otherwise, I might as well just not describe it at all and just say "it's a TPF API“.

> But you will never be able to describe all hypermedia operations/links in a machine-readable manner. At least not in the sense that machines can "understand" it.

That's not the goal; the goal is to reduce the API
to symbols the client knows and can manipulate.

The question is: how do we choose that set?
It should not be too complex, but not too simple either.
Too simple means every use case is a one-off.
Too complex means nobody will use it.

A minimal set of symbols includes for me
at least the possibility to describe
how a form creates a view from a collection
for basic combinators such as AND and EQUALS.

If we can't say in Hydra that
“this view chooses items of the collection
 that have equal values to your input”
than we cannot do a lot with Hydra.

If we do allow that in Hydra,
we should make that mechanism extensible
to support other ways of defining views in the future.
Otherwise, it's again a one-off.

That's the path that I want to choose.

> However there's great value in machine-readability where all of the API metadata is processed at runtime.

That value is limited if the metadata is simply "this API is TPF",
which what Dietrich proposes comes down to in the end.

(Yes, there was more complexity to his proposal than that,
 but it comes down to having very specific constants
 such as "TPF" pre-coded. I'm against that. TPF is too specific.
 But TPF can be expressed with more generic components.)

> This is what hypermedia is all about and not about making the API client understand what it means to perform an operation, which reserves a seat at a concert.

World-changing operations are a different class altogether.
We are talking about *simple*,
read-only application state transitions here.

So let's keep the discussion focused:
explaining to a client in what way exactly
it can create a view from a collection.

Best,

Ruben

Received on Monday, 15 February 2016 20:56:40 UTC