Current player matches endpoint has two severe issues

In the absence of a public API, I am using the endpoints used by Halowaypoint itself.

Given the appropriate “spartan token”, this works as intended:

curl --fail -X GET “https://halostats.svc.halowaypoint.com/hi/players/itz%20so%20frosty/matches?start=0&count=20” # token omitted

However, there are currently two major issues with this that I would like 343 to fix, preferably in the existing endpoint and even more so in the (hopefully) upcoming official API:

  • Player matches seem to be returned in chronologically reversed order, which means that different data will always be returned for the same start index and count (given that the player has played at least one match in between the calls). This essentially means that one has re-fetch all player matches every time, which over time will be a LOT of calls to your API that could have been avoided. I would suggest either making sure, by default, that player matches are always returned in chronologically ascending order or, at least, be able to provide a sortBy parameter.

  • Trying to fetch any player matches above a certain start index (seems to be around 1000) fails (as of this writing) with HTTP 500 (!)

Example:

curl -v --fail -X GET “https://halostats.svc.halowaypoint.com/hi/players/itz%20so%20frosty/matches?start=1000” # spartan token omitted

results in:

curl: (22) The requested URL returned error: 500

whereas:

curl -v --fail -X GET “https://halostats.svc.halowaypoint.com/hi/players/itz%20so%20frosty/matches?start=900” # spartan token omitted

succeds.

And similarly:

curl -v --fail -X GET “https://halostats.svc.halowaypoint.com/hi/players/b00mp0ps/matches?start=900”

result in (succeeds but no data = correct):

{“Start”:900,“Count”:25,“ResultCount”:0,“Results”:,“Links”:{}}

but

curl -v --fail -X GET “https://halostats.svc.halowaypoint.com/hi/players/b00mp0ps/matches?start=1000”

curl: (22) The requested URL returned error: 500

Could you please look into this?

Please let me know if you want me to provided more information.

To be fair, the consequences of the first bullet is not entirely true. One can fetch the player matches and then break processing when one encounters a previously processed match id. It just requires more book-keeping on the client side, which is ok, albeit not optimal.

The API wasn’t designed for public consumption. Presumably, it behaves the way that they intended for use by HaloWaypoint, so I don’t really see it as an issue. Also receiving results by descending time order is a pretty common use case for all kinds of APIs. It’s not an obvious problem, as you’re suggesting. It really depends on the use case.