When I make the following request:
POST /RestApi/v1/Search/EquitySearch HTTP/1.1
Host: hosted.datascopeapi.reuters.com
Authorization: Token <token>
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: f0cacf9b-0998-4e87-1385-e984cc32b255
{
"SearchRequest": {
"ExchangeCodes": ["NEO"]
}
}
I get back the seemingly appropriate response with a list of 250 objects under the 'value' key. There is also the @odata.nextlink": "https://hosted.datascopeapi.reuters.com/RestApi/v1/Search/EquitySearch?$skiptoken='MjUw'
However, when I follow the nextlink with the following request:
POST /RestApi/v1/Search/EquitySearch?$skiptoken='MjUw' HTTP/1.1
Host: hosted.datascopeapi.reuters.com
Authorization: Token <token>
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: f8126ddd-e95c-891d-3fe6-8ecae3d5b097
{
"SearchRequest": {
"ExchangeCodes": ["NEO"]
}
}
Instead of getting the next batch of items (presumably another 250, the same as the default for the first) I get 500, including the first 250 from the previous request and response.
Following the next nextlink yields 750, including many, but not all, of the items from the previous two requests.
As I follow the nextlinks the response size increases, and eventually reaches a steady state where new nextlinks are returned but the returned values are the same every time.
This behaviour occurs both in Postman and in custom Python code using the requests library. Manual pagination using the $top and $skip parameters yields similar results. Through experience, this particular query has ~5600 unique objects in its result set, and if I request a maxpagesize of 6000 I get them all in one request.
I have used the odata.nextlink pagination method successfully with the VenueByDay endpoints for retrieving large numbers of venue files, so I don't believe my implementation of the handling of odata.nextlink is at fault. Is it possible that there is an ordering issue server-side?
