See related discourse thread - most of the "meat" from that thread is recreated below.

synopsis

I'm looking for a machine read-able version of collection edit history - i.e. of pages like:

1. example of an edit history for a works collection
2. example of an edit history for an artist collection

context: trying to avoid excessive polling of api

I'm assessing whether to use musicbrainz for a project - still at proof-of-concept stage - that would use only a very small subset of mb data.

My present thinking on approach is to request the data I need once, via api, caching the responses into a local document store that my app would then use (instead of repeatedly hitting the api directly). This would improve the performance of my app and would essentially eliminate any impact of my app on the seemingly always stressed musicbrainz servers.

I suspect this pattern could be useful, and perhaps even promoted, to other client developers as a means to reducing load on mb servers, and also as a lower barrier to entry than a full db clone.

problem: notification of change

The challenge of the above approach is that I'd need to know when the upstream data changes so I can refresh my locally cached copy. Given existing resources, I could certainly execute a regularly scheduled iteration over every cached resource, polling for changes, but that would not be a great solution for me or you.

proposal: expose "edit" resource

Though I suspect, in terms of the "bigger picture", it might be worthwhile to discuss a more robust notification system (e.g. publish/subscribe), I believe this much more modest option would be a rather valuable enhancement:

1. Expose an "edit" resource via the webservice - Each edit appears to already be a discretely identifiable resource - e.g. edit #37148588.
2. Allow browsing of this "edit" resource via collection - Based on the collection UIs available via the website interface, it seems like all of the data is properly hooked up in the schema to associate edits with collections.

how this solves my problem

Much as I can already browse works in a collection via a GET like /ws/2/work?collection=19d9574a-22ff-4bbf-919b-39ea379f854a, this enhancement would enable me to browse edits to entities in a collection via a GET like /ws/2/edit?collection=19d9574a-22ff-4bbf-919b-39ea379f854a.

Rather than a regularly scheduled polling of all cached resources, I'd a have a regularly scheduled polling of just this one resource, which would then provide sufficient information for my application to know when a cached resource needs refreshing.

example data-flow I'm imagining

1. client cares about some set of works gathered into a collection; e.g. orchestral piano canon
2. perhaps daily, client script does a single GET to endpoint (does not presently exist): /ws/2/edit?collection=19d9574a-22ff-4bbf-919b-39ea379f854a
3. client script parses xml / json response to determine whether the edits are note-worthy, given the context of its usage of that data ... for example, an edit that adds a new recording relationship to the work might be relevant, and might result in a follow-up api request to get details of the newly associated recording, whereas an edit that simply adds a date to an existing recording relationship might not be relevant and might therefore not require any additional api requests