Valarauka.2719:

Hi guys! First off, thanks for this, it’s awesome.

I’d suggest adding item names to the response output for the item and recipe queries, either by default or gated by an extra parameter. Mostly because with the current response output, any lookup I imagine (e.g. for a recipe) will immediately be followed by n lookups to the item_details to get the names of all the items involved, which a) slows things down, and b) increases load for you guys — unless everyone caches those locally which brings up other issues.

something like:
items.json?names=1
response: {[ {id=5613, name=“Tiny Scale”}, {id=5614, name=“Small Scale”}, ….]}
(similar for recipes.json)

recipe_details.json?names=1 —> add “output_item_name” at the top level, and then “name” inside each ingredient record.

That way you can get human-readable output from a single query without needing to do fetches for each individual id to figure out what they mean…

Cliff Spradlin.3512:

Basically it sounds like you want a bulk API for lookup.

That’s a reasonable request, though I’d ask that you try the API in its current form as bulk APIs come with a number of extra complexities.

In testing, we found that using multiple threads and HTTP pipelining we were able to download the entire database of information from the API very quickly.

Crise.9401:

I would suggest an ID to name mapping, much like with some of the other apis… if for nothing else for sake of some consistency. HTTP being stateless… multi threading is not something that all… particularly some server side implementations would necessarily want to worry about right out of the gate, it places significant constraints and is prone to race conditions and corner cases even when done “correctly” (of course this is subject to the environment used).

For the OP: consider an implementation side cache to decrease total api requests and store any potential satellite data… not like you will need to make fresh lookups for every request nor should you, for things like items and recipes in particular.