Ik wil mijn API uitbreiden met het content type application/vnd+geojson zodat een response ook direct op een kaart geplot kan worden. Voor één enkele resource is dit geen enkel probleem, maar als ik dit op collectieniveau wil doen (bijvoorbeeld een zoekopdracht waar 5.000 resultaten uitkomen) dan wil ik door mijn totale FeatureCollection heen kunnen pagineren. Standaarden zoals application/ld+json en application/hal+json bieden hier handvatten voor door hypermedia navigatielinks op te nemen in de response. Is hier ook een standaard of best practice voor bij GeoJSON? Uiteraard kan ik extra links toevoegen aan de response maar dan is het geen valid GeoJSON meer. Ik zit zelf te denken aan de response headers, maar ben dus benieuwd of iemand hier al eerder over heeft nagedacht 
Typische reactie uit de geo-wereld is om de response niet in pagina’s op te delen, maar in verschillende kaarten, die een gebied van 256 bij 256 pixels bedekken. Inderdaad, we maken dan tiled GeoJSON https://github.com/mapbox/awesome-vector-tiles. Hierbij is er dus geen enkele relatie, verwijzing tussen de ene tile en de andere tile, alleen dat het van dezelfde endpoint komt.
Wat gebeurt er dan als er binnen 256 pixels 4.000 features zijn? Krijg je dan één FeatureCollection van tig duizend regels terug?
Gaat het om GeoJSON die je uit een bestand haalt / laadt? Of laadt je de data via een WFS?
In geval van het laatste, als de WFS via PDOK komt (–> WFS 2.0 met GeoJSON ondersteuning), kan je met het startindex attribuut) en het count attribuut (aantal features) wel wat bereiken:
Helaas staan de URLs voor opvragen van de volgende/vorige X objecten er niet in bij GeoJSON (wel als je GML opvraagt via WFS). Dus dat moet je dan zelf bijhouden.
Ooit wat over geschreven als je meer wilt weten: http://www.brentjensgeoict.nl/2014/01/29/haal-meer-data-en-geojson-uit-een-pdok-wfs/
Sorry, net niet goed gelezen: het gaat om je eigen API. Dus dat WFS verhaal is voor jou niet gelijk relevant. Een andere manier ken ik niet gelijk, om dat binnen GeoJSON zelf op te lossen.
Navigatielinks opnemen bij de FeatureCollection is wel het mooiste (dat doet WFS trouwens bij GML). En ik zie niet dat GeoJSON verbiedt om andere properties op te nemen, maar goed, dat is een beetje een juridische benadering van een spec ;).
Hoe doet WFS dat bij GML? Heb je daar misschien een voorbeeld van?
het FeatureCollection element bevat attributen ‘next’ en ‘previous’. Daarin staan die links.
Volgens RESTful Web APIs: Services for a Changing World - Leonard Richardson, Mike Amundsen, Sam Ruby - Google Boeken is er 1 hypermediacontrol in een featurecollection en dat is om het gewenste coördinatenstelsel te veranderen. Helaas is pagina 127 geen onderdeel van dit voorbeeldboek dus ik weet niet hoe dat dan werkt. Enig idee?
EDIT
Gevonden, het gaat om de volgende CRS notatie:
"crs": {
"type": "link",
"properties": {
"href": "http://example.org/mygrid.wkt",
"type": "esriwkt"
}
}Dit is zo te zien ook valid geojson, dus lijkt mij de beste optie!
{
"type": "FeatureCollection",
"_links": {
"next": {
"href": "http://nextpage"
}
},
"features": [
{
"type": "Feature",
"properties": {},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
4.65545654296875,
51.80521825434942
],
[
4.65545654296875,
51.981496940474585
],
[
5.16632080078125,
51.981496940474585
],
[
5.16632080078125,
51.80521825434942
],
[
4.65545654296875,
51.80521825434942
]
]
]
}
}
]
}Dat ziet er goed uit. Kunnen het altijd nog als best practice gaan pluggen