osu-web icon indicating copy to clipboard operation
osu-web copied to clipboard

Make `/users?ids=[]` endpoint public

Open stanriders opened this issue 3 years ago • 5 comments

We're developing a website that requires frequent batch-updating players' statistics (potentially on all rulesets as well) and /users endpoint seems to be a perfect fit for that, except it's locked to be lazer-only. Would it be possible to make it public?

Another good option would be adding all ruleset for either /me or /users/{id} endpoint to cut down api calls from potentially 4 calls per user to just one.

stanriders avatar Apr 14 '22 18:04 stanriders

Hmm, the reason this hasn't been exposed is that we would need to consider potentially different rate limits to match the single user lookup rate (to avoid abuse). Can you explain your specific use case to give a bit of context? Do you expect to be doing very high throughput, or looking to reduce turnaround time to get all the data you need?

peppy avatar Apr 15 '22 06:04 peppy

@peppy The use case is updating user statistics as regular as possible (ideally once a day or so). The website in question is gonna be pretty much google forms with osu integration, so for example if we have a registration form for a tournament it can have hundreds (worst case thousands, see 5wc) of players registered and we'd like to keep them all up to date. Even if doing that would not be possible, we'd still need to update players statistics when the form locks (so for example when tournament registration ends and ranks are finalized) and that will require batch-updating a lot of users.

stanriders avatar Apr 17 '22 20:04 stanriders

Okay. And currently things work fine but you're just making more API calls than you'd like to?

peppy avatar Apr 20 '22 07:04 peppy

You could say that. Website in question didn't launch yet so it's hard to say how much it'll stress the API, but it'd be good to circumvent that early rather than later.

stanriders avatar Apr 21 '22 16:04 stanriders

I think it's fine to expose this endpoint as long as it matches expectations of other endpoints (ie. it should not deprecate the existing user lookup endpoint due to containing more data, and if it does, the other endpoint should be updated to match). We don't want to start returning more data than the average user requires and causing larger throughputs unnecessarily.

peppy avatar May 03 '22 08:05 peppy