You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The endpoints getRandom{Anime,Manga,Characters,People,Users} only return a single resource. For my use case, I need to get a lot of random resources at once, specifically characters, and I want to avoid straining the jikan api.
Describe the solution you'd like
Give the endpoints an optional parameter limiting how many resources to return, default to 1, and return that many random resources. In fact it seems like there's already an optional parameter to the function that give random resource ids. My concern is that it requires jikan to do multiple requests to mal, as it doesn't seem like mal has any source of random resource in both their site and their api, which in turn forces jikan to limit it to a single resource to avoid requiring an order of magnitude more requests to mal. If this is the case, I still think allowing at least a small group of random resources (say up to 10) would be better overall, as it will at least lower the number of requests jikan has to receive even if it has to make the source amount of requests to mal overall. I'm not sure how the rate limiting works but maybe these can also cost more, so the end result is terms of rate limiting is the same but some requests are saved.
The alternatives below can also be relevant for the implementation of these endpoints in jikan.
Describe alternatives you've considered
Trying to use a pseudo-random group of resources by combining different endpoints that are paged
This is a bit hacky but can be pretty effective at reducing the number of requests. For to get n resources, divide them into m groups of n/m and for each one search for a random string of letters randomly and randomly selection a descending or ascending sorting then combine them together. You can even mix between different endpoints.
Most users of these endpoints will probably use them multiple times and even if they don't need multiple at once they can lower the number of requests and reduce the time waiting for a response by doing less requests for more resources. Also as far as I'm aware adding more parameters shouldn't be a breaking change as long as their default value produces the same result as before.
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Is your feature request related to a problem?
The endpoints
getRandom{Anime,Manga,Characters,People,Users}
only return a single resource. For my use case, I need to get a lot of random resources at once, specifically characters, and I want to avoid straining the jikan api.Describe the solution you'd like
Give the endpoints an optional parameter limiting how many resources to return, default to 1, and return that many random resources. In fact it seems like there's already an optional parameter to the function that give random resource ids. My concern is that it requires jikan to do multiple requests to mal, as it doesn't seem like mal has any source of random resource in both their site and their api, which in turn forces jikan to limit it to a single resource to avoid requiring an order of magnitude more requests to mal. If this is the case, I still think allowing at least a small group of random resources (say up to 10) would be better overall, as it will at least lower the number of requests jikan has to receive even if it has to make the source amount of requests to mal overall. I'm not sure how the rate limiting works but maybe these can also cost more, so the end result is terms of rate limiting is the same but some requests are saved.
The alternatives below can also be relevant for the implementation of these endpoints in jikan.
Describe alternatives you've considered
Trying to use a pseudo-random group of resources by combining different endpoints that are paged
This is a bit hacky but can be pretty effective at reducing the number of requests. For to get n resources, divide them into m groups of n/m and for each one search for a random string of letters randomly and randomly selection a descending or ascending sorting then combine them together. You can even mix between different endpoints.
welp I'm pretty much out of ideas.
Teachability, Documentation, Adoption, Migration Strategy
Most users of these endpoints will probably use them multiple times and even if they don't need multiple at once they can lower the number of requests and reduce the time waiting for a response by doing less requests for more resources. Also as far as I'm aware adding more parameters shouldn't be a breaking change as long as their default value produces the same result as before.
The text was updated successfully, but these errors were encountered: