More efficient way to request a lot of players

[mdashlw]

It was a part of #229, but since it's locked now, I guess I can open a new issue.

Currently, to get many players objects from uuids (like guild members, leaderboards, friends), you need to make a massive amount of queries, and the api key will throttle if you were to do it all at one moment. This is the issue. The reason why I'm opening this issue instead of contacting support and getting a higher limit is that my bot usually makes less requests than 120/m, the only way it can exceed this limit is requesting guild members.

Current solutions:

• Chunk queries - not exactly a solution, but a workarond, is unpleasant for users as well, they will have to wait a few minutes to see guild members.
• Use multiple api keys - forbidden, but the easiest way, so more people will stick to it, which is a problem for you, I guess.

Possible ideal solutions:

• Introduce a new endpoint for basic stats for a player, that has its own ratelimiting and probably uses caching. Same as the internal api website (/api/players/:name) mentioned in https://github.com/HypixelDev/PublicAPI/issues/229#issuecomment-626765471. Looks like the best solution as it solves many cases at once.
• Query flag for current endpoints, indicating whether to include basic info about players (basic info = the same as above endpoint would return)
• Raising ratelimit from 120/m to 1200/10m or 600/5m. Solves the problem in a way. I must say that mojang api uses 600/10m, it is even stricter than hypixel, but I rarely have problems with it.

[TheNullicorn]

New endpoint for basic player info that doesn't eat an api key (key is still required, just queriesInPastMin is not incremented) and probably uses caching. Same as the internal api website (/api/players/:name) mentioned in #229 (comment). Also solves related issues, not only guild members.

This is probably the best solution, since if they were to add player previews to the guild endpoint, they should also add them to the friends endpoint, boosters, leaderboards, and any other place where multiple players are referenced by UUID, which would probably be a huge hit on their end. If it gets cached (which for this endpoint, would make perfect sense), on top of the information listed in the #229 comment, a cachedAt field would also be very helpful.

I might suggest renaming this issue since it applies to other endpoints beyond the guild endpoint. A guild can have up to 125 members, but a leaderboards response can contain hundreds of players, and players can have thousands of friends. Honestly, such an endpoint would probably be abused, but what if it had its own rate limit much higher than the rest of the API?

[ConnorLinfoot]

We don't think this is an issue that needs us to change the API implementation including adding new endpoints. Users of the API should be utilizing caching, spacing out requests, and the Mojang API where needed rather than us implementing changes.

If users of the API have a genuine reason to need to often make high amounts of requests even with the above in place they can contact us for an API limit increase.

[mdashlw]

Users of the API should be utilizing:

• caching - I do cache the basic stats of a player, but to cache it you need to request it which becomes an issue when there are a lot of players.
• spacing out requests - you mean chunking? That's not really a solution, also I wouldn't want users to wait minutes to see guild members.
• the Mojang API where needed - I need to display the formatted name including rank/prefix so well.

If users of the API have a genuine reason to need to often make high amounts of requests even with the above in place they can contact us for an API limit increase.

I said this in the issue: generally I don't exceed the limit, it only happens when fetching guild members upon a user request. And higher limit doesn't even solve the problem, if many users will want to see guild members at the same time, it will exceed the new limit.

I don't see why first option can't be implemented. It benefits for both sides:

• the new endpoint would use caching, meaning you would hit the database less often
• the response is significantly smaller, so less to serialize for you, deserialize for us, meaning request would complete faster
• this solves probably the main reason why people need higher limit, so they wouldn't need to contact support, meaning less people with high limit, less work for support

And this endpoint is even already implemented and used in internal website api, so I don't really see a reason why not move it to the public api, it's not hard, it easily solves the stated issue and will decrease load on the api