Add ability to retrieve which content ids have changed between builds.

[lye]

When content is updated between builds (e.g., an item's name or icon changes) right now there's no way to get the changes without a full re-index on the application-side. For the items endpoint, the dataset is ~700+MB. It would be ideal if the API provided the ability to retrieve only the changes between builds to reduce the transfer required to keep an up-to-date database.

[codemasher]

Now that would be a thing. I suggested this ages ago already and mentioned some ideas how i'd put it under the /build endpoint (back then). If only i could find that post again...

Edit: well, i found some fragments:

An API which delivers all IDs of changed items for a given build (and therefore an API which delivers the recent build numbers – this could be done by the already existing build.json)

[lye]

I'm actually tempted to just implement this one weekend outside of the official API infrastructure -- I think there's a way to do this internally using the patch servers (since they I believe have access to the necessary information) -- but because all the API systems are stateless there's no real way to track deltas. With an external service, tracking state is a non-issue, so the implementation would be fairly straightforward.

Too many projects, too little time. sigh

[LithMage]

So any progress upon this? :) I am building my own application and this is one of the areas where it would be a huge improvement.

[lye]

Nope, still ENOTIME. I don't expect this will be done within the next six months.

[milneti]

Just while I am thinking of it I will drop it here to keep it around. Would this be able to provide us a content type as well?

Like: items [{id},{id}] , dyes [{id},{id}] , minis [{id},{id}] , ...

[lye]

Yeah, that's the intent. The backend can currently only have a single patch's data loaded at a given time (and is mostly stateless) so it's going to take a good deal of effort to make this feasible.