-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paginering #1
Comments
JSONAPI specifieert pagination op volgende manier:
Een concreet voorbeeld:
De invulling van de query parameters is relatief vrij (voorbeelden staan op de website), de query parameter |
Streaming kan ook een nuttig alternatief zijn voor expliciete paginering, aangezien dit al native support heeft in vele HTTP libraries. |
In vebrand met pagination: Ook standaardisatie nodig rond input parameters voor paginatie?
Rond steaming Mogelijk te ondersteunen: |
het lijkt met niet wenselijk om de input parameters te standardiseren, aangezien dit eerder limiterend werkt. Niet voor alle data(bronnnen) zal paginering werken met offsets bijvoorbeeld. Het gebruik van links om naar volgende en vorige pagina('s) te gaan biedt hier meer vrijheid. Mbt streaming: dit wordt in de praktijk nog niet veel gebruikt en standardiseren hierop lijkt me eerder voorbarig. |
stel dat we afspraken van de hypermedia links willen maken, leggen we dan ook vast de voorkeursterminologie:
of
of is dit vrij te kiezen. |
ivm de discussie of header versus payload. Met de header aanpak kunnen we enkel de voorgedefinieerde ondersteunen. Voor mij zou dit enkel aangeraden worden om die toe te voegen als die ook in de payload zitten. Voor het argument: "maar headers kunnen ook andere relaties ondersteunen". Je kan die wel niet eenvoudig mappen op de semantiek. Met een json-ld context is er een generiek machinaal toepasbare methode om de semantiek te koppelen aan de payload. En dat is niet mogelijk met de header aanpak. |
Ik zou geen voorkeur-strategie opleggen omdat ik merk dat we daar geen concensus in zullen vinden. Wel zou ik zoveel mogelijk versies proberen ondersteunen (zowel in HTML met |
Kunnen we dan de verschillende aanvaarde varianten oplijsten. Want ik denk dat dit een begin is om het verhaal concreter te maken. |
In het lijstje van gekende varianten kunnen we ook de paginering opnemen die voorkomt in alle samples van Spring Boot en Spring HATEOS: Uiteraard is het gebruik van booleans voor 'first' of 'last' geen goede manier van werken, maar een variant waarbij we die first en last weglaten en daarnaast het links-element van JSON API opnemen zou een aanvaardbare manier van werken kunnen zijn. |
@sophiekemper Ik denk dat we best de beste niet conflicterende en goed gedocumenteerde specificaties enkel ondersteunen. HAL, JSON API en HYDRA komen daarbij het dichtste bij. |
kunnen we json-API en Hal syntax niet annoteren met een standaard json-ld context? en dan enkel stap 1 en 2 overhouden? Maar dan moeten we wel een uitbreiding aan json-ld voorzien dat om kan met substructuren ("links", "_links"). Dan kunnen we ook nederlandstalige paginatie toelaten:
|
Zou er eventueel zo kunnen uitzien zonder uitbreiding geloof ik (JSON-LD 1.1):
Indien keys nederlandstalig zouden worden (eerste, volgende, vorige, laatste) zou de response strikt genomen niet meer aan de JSON API of HAL spec voldoen? |
@jensscheerlinck inderdaad de "@nest" van json-ld 1.1 werkt. Dat betekent dus wel dat hiervoor we moeten aligneren op json-ld 1.1 wat nog een draft is. ivm nederlandstalige keys: de engelse termen zijn in de JSON-API specification ook de technische identificatoren, dus ja dan worden ze incompatibel. zie http://jsonapi.org/format/#fetching-pagination. HAL specifieert enkel "_links" en laat de rest vrij. Echter de Hydra aanpak geeft nog meer vrijheid omdat de betekenis niet vast hangt aan een technische term maar aan de interpretatie door de json-ld context. |
Ivm met de tekst: kunnen we ons baseren op een draft specificatie zoals Hydra, of moeten we een eigen json-ld context definiëren? |
Ivm met de tekst op sectie Semantisch Als je json-API paginering ondersteunt dan veronderstel ik dat je hele API json-API is. Je zal waarschijnlijk nooit half kiezen. Dus de vraag rijst: is JSON-API een specificatie die aan alle-afspraken voldoet? |
Ivm met de tekst. De voorbeelden en het algorithme matching niet. het voorbeeld json-API heeft |
ivm het algoritme: waarom stap 3 en 4 niet samen nemen in 1: |
ivm het algoritme: waarom niet previous als synoniem in alle stappen ondersteunen? |
tenslotte moeten we ook afspraken maken over de paramaters in de API request (page/limit/offset...)? O is dit niet noodzakelijk omdat de hypermedia navigatie controls meer als voldoende zijn. Beslissing graag opnemen in de tekst. |
Terechte vraag. In de veronderstelling dat de huidige Hydra properties nodig voor paginering (collecties, next, prev...) vrij stabiel zijn zouden we een eigen 'applicatieprofiel' voor paginering kunnen definiëren, eventueel gebaseerd op de draft specificatie voor paginering die momenteel gelinkt staat.
Momenteel is dit out of scope gelaten van de specificatie, aan de hand van deze opmerking:
Hier heb ik niet meteen zicht op omdat ik JSON API niet voldoende ken hiervoor. Misschien heeft @nvdk hier een idee over?
Aangepast + andere suggesties verwerk ik later nog.
|
Voor het pagineren van datasets kunnen verschillende standaarden gevolgd worden:
Er kan een algoritme geschreven worden om meteen alle standaarden te verwerken en zeker te zijn dat, als een pagina een volgende heeft, de volgende pagina gevonden kan worden. Een draft van zo’n algoritme komt hier: https://github.com/pietercolpaert/extract-page-controls
The text was updated successfully, but these errors were encountered: