Overcoming API rate limiting

MusicBrainz Development
1

can you explain this a bit?

2

The ‘resource’ parameter can be specified multiple times (up to 100) in a single query

The response will contain a url-list in this case, rather than a single top-level url, and any ‘resource’ that is not found will be skipped.

When fixing the original script this was one of the first things that had to be improved because I quickly ran into Chrome’s own throttling mechanism while testing and querying one URL at a time was way too slow for my taste. (Beatport can display up to 150 releases per page)

1 Like
3

they should do that for all things so you can always request multiple stuff (of any type)

4

You mean something like this?

5

i think so, for me it is mainly to get information quicker when parsing events like festivals and stuff.

for example:
if i want to get everything on rock herk 2025 Rock Herk 2025 - MusicBrainz
i have to request all these individually:

  • main event
    • day1
    • day2
      • day1stage1
      • day1stage 2
      • day1stage 3
      • day1stage 4
      • day2stage 1
      • day2stage 2
      • day2stage 3
      • day2stage 4
        so that is 11 requests as 1 request per second that = 11 seconds.

if i could group them i would end up at:

  • main event
    • day1 + day2
      • day1stage1 + day1stage2 + day1stage3 + day1stage4 + day2stage1 + day2stage2 + day2stage3 + day2stage4

this way i would ALWAYS (or almost always) have the full event in 3 requests.

if i would for example change to graspop 2025 Graspop Metal Meeting 2025 - MusicBrainz
it has 1 main event, 4 Day events, 6 stage events each day.
that totals to 1 + 4 + (4x6) = 29 requests

while if i could do multiple stuff it would be 3
1 of the main event that tells me the id’s of all the days
1 of all the days that gives me the id’s of all the stages for each day
1 of all the stages from all the days

going from 30 seconds waiting to load everything to 3 seconds would make a HUGE difference

2 Likes