Allow doing a query for all mods of a game in one query without knowing the game id.
leper opened this issue · 3 comments
(In my current WIP patch for 0 A.D. there need to be two queries before all the neccessary data is retrieved, because I don't hard-code the game id (to allow for different API endpoints, and to not force possible future users of the engine to use the same).
Currently the code does something roughly equivalent (to the following commands)
curl --request GET 'https://api.mod.io/v1/games?api_key=use_your_own&nameid=0ad'
# parse {"data":[{"id":57," ...
curl --request GET 'https://api.mod.io/v1/games/57/mods?api_key=use_your_own'
. It would be a lot nicer (and reduce the number of queries, even though the code will cache the game id after the first query (at least after some more integration work)) to be able to do a single request and get the result for the second query.
Also why does the first query even return an array of data if ids are unique, so there can only be 1 or 0 returned entries?
As I understand it, you are attempting to avoid hardcoding in your games id, by searching for it via its name id. This is to make it easier when others fork the 0 A.D. code to add their version to mod.io is that right?
While I can understand that, either way you have to code in some kind of config to enable this, so i'm not sure this is required.
We can consider an undocumented endpoint that does what you require, but would prefer to avoid this as we made a design decision a while ago to include ID's in URLs (since most games are singular!) so it be a big change to revert this design decision.
The nameid parameter is currently stored in a config file. So other games can already change it if they want to.
This is more trying to avoid too much reliance on a single API provider, or multiple API providers having the same IDs. (Or one API provider having broken backups and an incident which results in loss of some data and new IDs being handed out.)
The somewhat strange part about IDs in URLs (which is fine, given that it most likely makes actual queries on the underlying DB easier) is that there already is something called "nameid" which I presumed would be a nice fit in that place. Especially I consider that some A-Za-z_ string which given the name of the field should already be unique and some short representation of games which I would assume multiple API providers could actually agree on.
True, the nameid is primarily used by the website - as the URL to your content. For example you can see the nameid in action here:
Because games occasionally rebrand, it is possible that the nameid could change - so it isn't a true id. I might put this request down in "future" consideration column, but for now advise you to either do what you are doing, or use the id.