Example (nothing like the spec).
"CC24 D1 R6: Munster vs Lanarkshire","url":"https://www.chess.com/club/matches/1616329","@id":"https://api.chess.com/pub/match/1616329","club":"https://api.chess.com/pub/club/munster","results":{"played_as_black":"resigned","played_as_white":"checkmated"},"board":"https://api.chess.com/pub/match/1616329/13"},{
Richard, I'm guessing that if the 'white' game finishes first then it's entered into the endpoint data followed by the 'black' game when it concludes but if 'black' finishes first, it comes before the 'white' result?
Does the order matter a great deal? I rely on those results a lot but the order of white & black is unimportant.
Stephen, That's not the point. We have a spec, which I programmed to. Yes I can accomodate the change without difficulty.
My main point is we have a published spec which now means nothing, and a changelog that hasn't been used for 6 years.
These sort of uncontrolled changes by devs indicates that the development process is totally out of control. We have seen it is many areas of the site.
Richard, you do realise the Published-Data API for this endpoint is incorrect because it shows the white/black game results as being in the form of a list whereas they're actually in the form of a dictionary (associative array)?
In reality any player/matches endpoint shows this...
"results": { "played_as_black": "resigned",
"played_as_white": "win"
},
The documentation wrongly shows this...
"results": [ "played_as_white": "win", //result of game ... "played_as_black": "win" //result of game ... ],
Strictly speaking dictionaries are not ordered in the way lists are. Indexing is by means of keys which may be stored in any order.
That is exactly my point. It has changed in the last 48 hours.
Two days ago my code worked and has for the past 4 years.
I only come across those keys when I'm processing tournament matches and the endpoint data is typically like this...
{
"username": "bashmachnik-1810",
"stats": "https://api.chess.com/pub/player/bashmachnik-1810/stats",
"status": "basic",
"played_as_white": "checkmated",
"played_as_black": "win",
"board": "https://api.chess.com/pub/match/1221402/5"
},
.
So there's no doubt that dictionary format (/json?) is being used. In the case of that endpoint no reference whatsoever is made to game results!
That is exactly my point. It has changed in the last 48 hours.
Two days ago my code worked and has for the past 4 years.
But what's changed? The endpoint(s) still look correct so I thought this was simply a documentation error.
I don't usually use the player/match endpoint so were game results previously in list format?
It's changed from the published spec to what you see now in the endpoint output.
They have probably done it to get a consistant format. But to do it without telling us and without changing the spec. Again!
But the published layout as given here...
https://www.chess.com/news/view/published-data-api#pubapi-endpoint-player-matches
...is nonsense. It shows the results as key-values within a list which isn't one form of container or the other. Has that been like that for years?
And the endpoint couldn't have been structured in that way because it would fail to get past the json-parser surely? I think it would flag up errors in the endpoint.
Correct And that is not what the endpoint now produces. But it did 2 days ago.
I am not saying the change is wrong: I am saying they changed it without publishing the change.
I have asked about it and at this point it appears there was an update in an associated library the API uses (or the code that feeds it) that may have introduced the change. The API itself wasn't modified.
It's possible the documentation will need updated but as soon as more information is available I'll reply again.
I'm lost - I don't understand how that endpoint format could ever have worked as shown.
I have asked about it and at this point it appears there was an update in an associated library the API uses (or the code that feeds it) that may have introduced the change. The API itself wasn't modified.
It's possible the documentation will need updated but as soon as more information is available I'll reply again.
Would it also be related to the broken team members endpoint (see other topic)?
I'm lost - I don't understand how that endpoint format could ever have worked as shown.
As I use spreadsheets exclusively, I never use any canned programs. I write all my routines specifically to the specification of the endpoint.
Code re-written for the change and seems to be working now.
Will be interesting to see how long it takes for the devs to finish the job completly. The jobs not finished until ALL the paperwork is done.
I've just remembered that there is a function I use in which I download 'player/matches' endpoints and I've run it within the last year.
So something's awry here because I'm 99.9% sure the json parser that's bundled with the Python Requests module I use would never allow that method of formatting in a json string. I would expect to see a lot of red error messages!
I don't question that something has changed but I'm not convincd the endpoint was ever formatted in the way it still describes in the documentation. Having said that it isn't the player results data I use but something else. Even so, the entire string we download has to go through the json parser, so when it came to the first of the player results I think it would have flagged an error.
Seems this endpoint for player results, has been changed without any notice .
This is the spec:
"results": [ "played_as_white": "win", //result of game played as white, see "Game results codes" section "played_as_black": "win" //result of game played as black, see "Game results codes" section ],