`GetUserSummary` Awarded return type varies based on criteria

[LaunchBox-C-Beats]

When using the GetUserSummary end point the return type for the Awarded property isn't consistent. When passing a value of 5 for both count parameters Awarded is returned as a dictionary. If you pass 0 for those same parameters the property is returned as an empty array.

[wescopeland]

Transferred to RAWeb.

[LaunchBox-C-Beats]

RecentAchievements property does the same

[LaunchBox-C-Beats]

I am doing some string replace logic in my code to compensate, so this isn't critical for us at the moment (in case you need this information to correctly triage where to place your efforts).

[MSGoodman]

Could this be as simple as changing the relevant lines in API_GetUserSummary.php from

// if no games were requested, initialize empty arrays for Awarded and RecentAchievements
$retVal['Awarded'] = [];
$retVal['RecentAchievements'] = [];

to

// if no games were requested, initialize empty arrays for Awarded and RecentAchievements
$retVal['Awarded'] = json_encode(new stdClass());
$retVal['RecentAchievements'] = json_encode(new stdClass());

and updating the related test in UserSummaryTest?

Or is there a more elegant solution?

Also, as much as I like consistency, are we worried that this might break other applications that expect this to return an empty array instead of an empty object?

[wescopeland]

are we worried that this might break other applications that expect this to return an empty array instead of an empty object?

Yep -- most of our API changes are additive (new data or new endpoints altogether) rather than tweaking existing stuff. Almost every time we've changed something, no matter how small or seemingly insignificant, it has come back to bite us.

Eventually we'll roll out a V2 of the API that hopefully is a bit more resilient and allows users to more properly structure their expected response in the request (ie: GraphQL, OData, trpc, etc). Either that, or it will actually be a RESTful API.

Unfortunately even though the request here is perfectly reasonable, it will likely cause some breakage out there in the ecosystem.

[MSGoodman]

Makes sense to me. What do we do here then, just close the issue?

[Jamiras]

Unfortunately even though the request here is perfectly reasonable, it will likely cause some breakage out there in the ecosystem.

I think this change is perfectly reasonable. The client shouldn't have to look for both a dictionary and/or an array for a specific field. A similar fix was made for another API (see #484)

https://github.com/Jamiras/RAWeb/blob/fc2e030c13e460930d47769d9807e125dbb3b123/public/API/API_GetGameInfoAndUserProgress.php#L59-L61

[wescopeland]

@MSGoodman I'm happy to defer to @Jamiras's judgment on this. Please feel free to proceed.

[wescopeland]

Resolved by https://github.com/RetroAchievements/RAWeb/pull/2143.