Anhim.3156:

Hiya,

I haven’t been able to find anything to this matter so I’ll ask here (knowing it’s probably been asked before).

I’m wondering if there is a way to get information on which API entries were updated (and possible when). I’m aware it’s easy to find if new entries were added simply by looking at the base point (say /v2/item) and looking at the number of entries; but this does not show if any already existing entries were modified (for example cooldowns on skills).

Thanks for any hints/answers.

Anh.

Lawton Campbell.8517:

The short answer is no.

There’s an open issue on github for this; the unfortunate bit is that the API frontend is entirely stateless (so it can’t persist data) and the backend that reads the dat file can only run the latest dat file (and is effectively also stateless) — and the dat file doesn’t have any versioning history.

So, to implement this on our side we basically have to rearchitect how data is obtained for a large portion of the API (basically, any endpoint that accepts a ?lang parameter). It’s something that I’d like to do at some point, but am currently unable to justify the massive amount of time it would take to implement.

I think the easiest solution is for end-users to basically clone the database (e.g., pull everything when /v2/build updates) and track changes locally. I realize that this is totally infeasible for webapps, but it’s the only avenue I can offer right now.

Sorry :<

Anhim.3156:

Alright, I figured as much.

The solution you suggest is something I am currently employing, but I am always concerned about minimizing queries to the API (since I don’t know much about the hardware/software limitations, I assume worse case).

With regards to my own project it doesn’t affect me too too much, since items are rarely updated (usually replaced). So far I’ve forced a check whenever an achievement is added to the categories, but I dislike the many many calls it does to confirm things are up to date.

Anyway, thanks for the in-detail answer and the link, hopefully some day this gets to be done (along with all other plans, because money and time are never a problem… right?).

Anh