pagination/next link

[matthewhanson]

Features API requires a next link (rel=next) on search results, which seems like it belongs in Commons, especially if #82 is done.

An issue with next link is what happens if the query was a POST request, because converting that to a GET request could be problematic for large queries. One way would be for the implementor to use sessions and return a token to get the next page of results, but we didn't want that to be required.

Instead we return a next link that also has fields for the body and headers so that the user can use those to make the request again, along with the parameters returned in the next link. It's not very elegant by any stretch.

Regardless, I think Commons should include the next link, and can discuss what to do in the POST vs GET case.

[cmheazel]

Included

[m-mohr]

While I see the next relation type being included, it's not clear how standards should behave in non-GET requests. Doesn't seem useful to let this open. Then each extension will define their own behavior. For reference, here's one "extension" defining it: https://github.com/radiantearth/stac-api-spec/blob/master/api-spec.md#paging-extension
cc @matthewhanson

[cmheazel]

@m-mohr The next association is based on the similar capability in WFS. It supports a serial progression through an ordered set of pages which constitute the response to a request. As such, GET is the only applicable operation.

[ghobona]

Cc: @pvretano @cportele This could be an enhancement for future extensions of OGC API - Features and Records.

[cmheazel]

@ghobona The support for the next association in API-Common is based on a similar capability in API-Features.

[cmheazel]

5/10/21 SWG - OK to close.