Pagination and querying scheme (Was: Re: Call for consensus for the pagination design (ISSUE-42))

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

> Or are these just separate resources provided by the API? Consider these
> examples:
>
> http://temp.uri/api/posts?page=1 - standard paging
> http://temp.uri/api/posts?date=2015-10-22 - should be this rised as hydra
> view mechanism?

I don't see that this has anything to do with paging. There's of
course quite a bit of overlap between pagination and querying /
search, but sticking strictly to pagination since its semantics are so
well defined (or at least easier to define than those of querying and
search) for Hydra Core seems like a good idea. Then we can perhaps
draw experience from OData for querying and plug that with other
technologies to fit Hydra. Just not Core, I think.

> http://temp.uri/api/posts/2015-10-22 - or should it be a feature of the API
> to be implemented by the developer
> http://temp.uri/api/posts/2015-10-22?page=1 - this still can be paged!
>
> Still, it might be worth of having something in hydra to tell client on how
> to construct some iri templates. I can imagine these situations:
>
> http://temp.uri/api/posts?page={?page} where ?page maps to vocab:pageNo
> http://temp.uri/api/posts/{?year}/{?month}/{?day} - where ?year, ?month and
> ?day maps to vocab:year, vocab:month, vocab:day
> http://temp.uri/api/posts?filter={?freetextSearch} where ?freetextSearch
> maps to hydra:freetextSearch
> http://temp.uri/api/posts?order-by={?property} where ?property maps to
> vocab:property
>
> This enables client to handle and combine these effectively. I hesistated to
> put all of these into hydra, but haview few extra predicates in an extension
> is of no use either.

As mentioned, I think this is out of the scope of Hydra Core. There's
a lot of technologies tackling this problem already (OData, Open
Search, etc. are mentioned). You also have the HTTP SEARCH method[1]
being specified, which may convey semantics we need to take into
consideration (or not). Still early days, but either way, I think this
falls outside the scope of Hydra Core.

>> absolutely not. So many variations, and really orthogonal to Hydra Core.
>
> Well, hydra should not become a querying API, but should provide few simple
> mechanisms to address common scenarios experienced in the wilderness.

I think the existing proposal for paging addresses this quite well and
if we do get an HTTP SEARCH method, Hydra can be extended to support
it without any problems, imho.

> OData unless some ORM like approach is used won't work with pure RDF (I
> think)

Plug some JSON-LD on top of OData, combine it with the HTTP SEARCH
method and you have everything you need, no?

____
[1] https://tools.ietf.org/html/draft-snell-search-method-00

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

Received on Tuesday, 27 October 2015 14:35:06 UTC