-
Notifications
You must be signed in to change notification settings - Fork 43
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
non compliant paging #70
Comments
If it's not clear from context whether to send GET or POST, would it be an option to add a method attribute (defaulting to "GET") to the links? That could be interesting anyway also for other (rare) use cases. |
But how do you provide a You'd have to cache the request and return a token that would be used to get to the next page, which is a bit non-trivial (especially for a serverless app). It seems easier to have a |
I must admit, that was not the best idea I had yesterday night. I thought about tokens, but forgot that in this case I don't need to send it via POST anyway. I guess the better place to discuss it is here: radiantearth/stac-spec#381 We probably should make a pro/cons list on every possibility (cursors/offset(pages)/next links/...) and then decide for one of them. I guess each of them has a big con though. (It always blows my mind when POST is used for things that GET should be used for.) |
The about-to-be-released version of STAC (0.7.0) now has |
sat-search uses the parameters
page
andlimit
when the number of Items is more thanlimit
.This is not compliant with STAC because STAC doesn't specify a mechanism to do paging. The assumption is that all results will be returned, although this may cause errors in some implementations, such as sat-api (see #69 ).
See the STAC issue discussing this:
radiantearth/stac-spec#381
One possible solution is to remove paging and instead use the
next
links. However,next
links unless combined with caching and session tokens, can fail if combined with lengthy POST rather than GET requests.If paging remains implementation specific then it will be difficult to make sat-search generalized enough to work with all implementations when the number of items searched for is larger than the max response size for the given implementation.
cc @vincentsarago @sharkinsspatial @m-mohr @cholmes
The text was updated successfully, but these errors were encountered: