RFC: Match Data

@skelos, thank you. The fix is expected to be rolled out today.

Great! After I had posted I recalled I'd seen mention of a fix for timeouts but didn't really know if it was release or merely identified and perhaps fixed in the unreleased code.

I'll be using the endpoint for a couple of matches:

1. To see how unbalanced they are (and then the admin team can decide whether to push to balance them or just give up)

2. If we push, it would be polite not to nag the people who have signed up already or who belong to both teams and therefore can't play for either side.

Breaking changes: please note that we have added a new section called "settings" that will include the Match settings. This change has been made to fit the same structure of the Tournaments data.

"settings": {
"rules": "chess",
"time_class": "daily",
"time_control": "1/86400",
"min_team_players": 1,
"min_required_games": 0,
"autostart": false
}

The documentation will be updated when the changes will be live.

Thanks. That's useful data and consistency is good.

@Dale00007 please look at the new proposal for the match endpoint. We would like to add two new fields for each player "played_as_white" and "played_as_black" that will show the result of each game played by the user (if the games are finished). I hope this change will help you to keep track of results without the need to poll all boards.

Yes. This would be helpful. I was not yet able to start doing my code for reading boards so I would notice that I need such item only later on ;-)

I'm using this endpoint quite heavily now, and the amount of duplicated data seems about right as my script for matches in registration state runs quickly.

(I have another report that can require data that takes minutes to fetch, minimum, and a third which can require data which takes hours to fetch. And caching is tricky. I'll discuss those reports sometime, mostly as feedback. I can cache and risk inaccuracies and inconsistencies and with the current API must.)

The one outstanding issue I have with this endpoint now is another api.chess.com vs www.chess.com inconsistency: timeout_percent is an integer in the JSON data but is shown with a couple of decimal points on the website. I would very much like the same data via api.chess.com as is visible on the website.

If I can't have (for whatever reason) the same data as is on the website, please document whether the data is being rounded or truncated (mathematically "floor" of the website value, I guess). I would prefer the floor of the decimal value if I cannot have the same precision as the website.

Rationale: For competitions (or merely teams with timeout policies) 14.99 is not 15.00. Some rules lawyer some day is going to say, "You are allowed to remove players with timeouts of 15% and higher. You should not have removed the player with 14.99%."

I am sure that day will be very, very, irritating and it of course looks like a "who really cares?" issue but trust me, people get quite invested in competitions such as TMCL and right now any report I write that hits the magic (for TMCL) 15% must put a question mark after it to tell the reader they need to check the value on the website.

@skelos here an example of a player info during the registration phase:

{"username":"duschgel","rating":1447,"timeout_percent":0.87,"rd":64.16,"status":"premium"}

"timeout_percent" and "rd" available as 2-digits floats.

Thanks Andrea. I'll run some tests tomorrow and update the one script I have that I think cares; it knows now to format timeout_percent as a three digit number and that will no longer be appropriate, but the change is good!

I doubt my calculations with Gliko RD will change but I will check them too, before and after.