GET Search with {'limit': 10001} returned status code 200, must be 400

[jjrom]

stac-api-validator returns an error when checking https://tamn.snapplanet.io endpoint with the following error
GET Search with {'limit': 10001} returned status code 200, must be 400

However in the stac-api specification it is written (https://github.com/radiantearth/stac-api-spec/tree/dev/item-search#query-parameter-table):

limit The limit parameter follows the same semantics of the OAFeat Item resource limit parameter [...]. If the limit parameter value is greater than the advertised maximum limit, the server must return the maximum possible number of items (ideally, the number as the advertised maximum limit), rather than responding with an error.

From this sentence I understood that the server should returns a result with HTTP 200 when limit is greater than the maximum expected.

[philvarner]

I re-read the OGC Features - Part 1 spec about this for the first time in a long time, and I misunderstood what it was constraining when I implemented this. I'll fix this and also clarify in;

• clarify meaning of limit radiantearth/stac-api-spec#334

also related is this issue:

• pull the advertised limits from the service description or use 1-10000 as defaults #19

[philvarner]

The correct behavior is what's defined in OGC API Part 1 - http://docs.opengeospatial.org/is/17-069r3/17-069r3.html

7.15.8. Error situations
...
A 400 will be returned in the following situations:
...
    If query parameter limit is not an integer or not between minimum and maximum;

Item Search will adopt the same semantics.

So, against, this validation error is correct, but for the wrong reason. in https://tamn.snapplanet.io/ , the responses should be:

limit - status_code

• 0 - 400
• 1 - 200
• 500 - 200
• 501 - 400

[philvarner]

Removed in https://github.com/stac-utils/stac-api-validator/releases/tag/v0.0.3 -- even though this validation error is correct (10001 is invalid b/c your api advertises 500 as the highest limit), it's an arbitrary value and an api could advertise a higher one

[aznan2]

Huh, I guess OAFeat contradicts itself, because in the previous section it's in line with how STAC behaved previously...

7.15.7 Respone
...
So (using the default/maximum values of 10/10000 from the OpenAPI fragment in requirement /req/core/fc-limit-definition):
...
* If you ask for 50000, you might get up to 10000 (server-limited) and if there are more, a next link;

[aznan2]

It seems that the intent in OAFeat is to allow limit values over the maximum - see opengeospatial/ogcapi-features#640 and opengeospatial/ogcapi-features#368. Should this change be reverted?

[philvarner]

Thanks for bringing this up, I don't even remember filing that issue against them, and didn't see it had been resolved. Filed this against he api: radiantearth/stac-api-spec#357