- From: elf Pavlik <perpetual-tripper@wwelves.org>
- Date: Fri, 23 Oct 2015 13:24:51 +0200
- To: Tomasz Pluskiewicz <tomasz@t-code.pl>, Karol Szczepański <karol.szczepanski@gmail.com>, public-hydra@w3.org, Dietrich Schulten <ds@escalon.de>
On 10/23/2015 01:10 PM, Tomasz Pluskiewicz wrote: > Hi Karol > > October 22 2015 10:22 PM, "Karol Szczepański" <karol.szczepanski@gmail.com> wrote: >> >> Actually with partitioning based i.e. on dates we cannot talk about pages! >> These are indeed partial views but I hesistate to call it a page when the >> view is on daily basis. >> Still, this doesn't change the general concept of a hydra:view. >> The question is, shall these cases with different partitioning schemes be >> elevated to specific views? >> 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? >> 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. >> > > I don't actually see where the problem lies. The hydra:view contains links to other views within the collection. For example the date could be > > GET http://temp.uri/api/posts?date=2015-10-22 > > { > @id: http://temp.uri/api/posts?date=2015-10-22, > view: { > next: http://temp.uri/api/posts?date=2015-10-23, > prev: http://temp.uri/api/posts?date=2015-10-21 > } > } > > The client shouldn't care what is the view partitioning scheme, only how to transition to another view. Yes, but request to http://temp.uri/api/posts would NOT return 'first' view but some n-th. Most likely with only 'prev' and not next (requires time travel)
Received on Friday, 23 October 2015 11:24:56 UTC